There's no stable release, yet, but you can get everything currently running on blerg.dominionofawesome.com by cloning the git repository at http://git.bytex64.net/blerg.git.
Blërg has varying requirements depending on how you want to run it — as a standalone HTTP server, or as a CGI. You will need:
As a standalone HTTP, server, you will also need:
Or, as a CGI, you will need:
I know I'm gonna get shit for not using an autoconf-based system, but I really didn't want to waste time figuring it out. You should edit libs.mk and put in the paths where you can find headers and libraries for the above requirements.
Also, further apologies to BSD folks — I've probably committed several unconscious Linux-isms. It would not surprise me if the makefile refuses to work with BSD make. If you have patches or suggestions on how to make Blërg more portable, I'd be happy to hear them.
At this point, it should be gravy. Type 'make' and in a few seconds,
you should have http_blerg
, cgi_blerg
,
rss
, and blergtool
. Each of those can be made
individually as well, if you, for example, don't want to install the
prerequisites for http_blerg
or cgi_blerg
.
While it's not required, Blërg will be easier to set up if you configure it to work from the root of your website. For this reason, it's better to use a subdomain (i.e., blerg.yoursite.com is easier than yoursite.com/blerg/). If you do want to put it in a subdirectory, you will have to modify www/js/blerg.js and change baseURL at the top. The CGI version should work fine this way, but the HTTP version will require the request to be rewritten, as it expects to be serving from the root.
Right now, http_blerg doesn't serve any static assets, so you're going to have to put it behind a real webserver like apache, lighttpd, nginx, or similar. Set the document root to the www directory, then proxy /info, /create, /login, /logout, /get, /tag, and /put to http_blerg.
Copy the files in www to the root of your web server. Copy cgi_blerg to blerg.cgi somewhere on your web server. Included in www-configs is a .htaccess file for apache that will rewrite the URLs. If you need to call cgi_blerg something other than blerg.cgi, the .htaccess file will need to be modified.
There is an optional RSS cgi (called simply rss) that will serve RSS feeds for users. Install this like the CGI version above (on my server, it's at /rss.cgi).
Blërg was created as the result of a thought experiment: "What if Twitter didn't need thousands of servers? What if its millions of users could be handled by a single highly efficient server?" This is probably an unreachable goal due to the sheer amount of I/O, but we could certainly do better. Blërg was thus designed as a system with very simple requirements:
And to further simplify, I didn't bother handling deletes, full text search, or more complicated tag searches. Blërg only does the basics.
Classical model |
---|
Client App HTML/Javascript |
Webserver Apache, lighttpd, nginx, etc. |
Server App Python, Perl, Ruby, etc. |
Database MySQL, PostgreSQL, MongoDB, CouchDB, etc. |
Modern web applications have at least a four-layer approach. You have the client-side browser app written in HTML and Javascript, the web server, the server-side application typically written in some scripting language (or, if it's high-performance, ASP/Java/C/C++), and the database (usually SQL, but newer web apps seem to love object-oriented DBs).
Blërg model |
---|
Blërg Client App HTML/Javascript |
Blërg Database |
Blërg compresses the last two or three layers into one application. Blërg can be run as either a standalone web server, or as a CGI (FastCGI support is planned, but I just don't care right now). Less waste, more throughput. As a consequence of this, the entirety of the application logic that the user sees is implemented in the client app in Javascript. That's why all the URLs have #'s — the page is loaded once and switched on the fly to show different views, further reducing load on the server. Even parsing hash tags and URLs are done in client JS.
The API is simple and pragmatic. It's not entirely RESTful, but is rather designed to work well with web-based front-ends. Client data is always POSTed with the usual application/x-www-form-urlencoded encoding, and server data is always returned in JSON format.
The HTTP interface to the database idea has already been done by CouchDB, though I didn't know that until after I wrote Blërg. :)
Early in the design process, I decided to blatantly copy varnish and rely heavily on mmap for I/O. Each user in Blërg has their own database, which consists of one or more data and index files, and a metadata file. When a database is opened, only the metadata is actually read (currently a single 64-bit integer keeping track of the last record id). The data and index files are memory mapped, which hopefully makes things more efficient by letting the OS handle when to read from disk. The index files are preallocated because I believe it's more efficient than writing to it 40 bytes at a time as records are added. Here's some info on the database's limitations:
maximum record size | 65535 bytes |
maximum number of records per database | 264 - 1 bytes |
maximum number of tags per record | 1024 |