X-Git-Url: http://git.bytex64.net/?a=blobdiff_plain;f=www%2Fdoc%2Findex.html;h=e98ef47f0e0804b0dbca756781828d5bc61731f4;hb=17bef4d5d8ed21748bbcd439d47d9b43d28b3501;hp=9a85061c81821c1ec30277e749b258d6497ae406;hpb=93ac2090dfae4917cfdd3324d35b60756f5dd8b3;p=blerg.git diff --git a/www/doc/index.html b/www/doc/index.html index 9a85061..e98ef47 100644 --- a/www/doc/index.html +++ b/www/doc/index.html @@ -36,6 +36,11 @@ C.
I know I'm gonna get shit for not using an autoconf-based system, but -I really didn't want to spend 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. +
There is now an experimental autoconf build system. If you run
+add-autoconf
, it'll do the magic and create a
+configure
script that'll do the familiar things. If I ever
+get around to distributing source packages, you should find that this
+has already been done.
+
+
If you'd rather stick with the manual system, 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
@@ -101,6 +112,9 @@ made individually as well, if you, for example, don't want to install
the prerequisites for blerg.httpd
or
blerg.cgi
.
+
NOTE: blerg.httpd is deprecated and will not be +updated with new features. +
While it's not strictly required, Blërg will be easier to set up if @@ -172,14 +186,13 @@ For the HTTP backend, you'll get nothing (since it will have crashed), or maybe a 502 Bad Gateway if you have it behind another web server.
All usernames must be 32 characters or less. Usernames must contain
-only the ASCII characters 0-9, A-Z, a-z, underscore (_), period (.),
-hyphen (-), single quote ('), and space ( ). Passwords can be at most
-64 bytes, and have no limits on characters (but beware: if you have a
-null in the middle, it will stop checking there because I use
-strncmp(3)
to compare).
+only the ASCII characters 0-9, A-Z, a-z, underscore (_), and hyphen (-).
+Passwords can be at most 64 bytes, and have no limits on characters (but
+beware: if you have a null in the middle, it will stop checking there
+because I use strncmp(3)
to compare).
Tags must be 64 characters or less, and can contain only the ASCII -characters 0-9, A-Z, a-z, hyphen (-), and underscore (_). +characters 0-9, A-Z, a-z, underscore (_), and hyphen (-).
author
field, like so:
There is currently no support for getting more than 50 tags, but /tag will probably mutate to work like /get. +
POST to /subscribe/(user) with a username
parameter and
+an auth cookie, where (user) is the user whose updates you wish to
+subscribe to. The server will respond with JSON failure if the auth
+cookie is bad or if the user doesn't exist. The server will respond
+with JSON success after the subscription is successfully registered.
+
+
Identical to /subscribe, but removes the subscription. + +
POST to /feed, with a username
parameter and an auth
+cookie. The server will respond with a JSON list of the last 50 updates
+from all subscribed users, in reverse chronological order. Fetching
+/feed resets the new message count returned from /feedinfo.
+
+
NOTE: subscription notifications are only stored while subscriptions +are active. Any records inserted before or after a subscription is +active will not show up in /feed. + +
POST to /feedinfo with a username
parameter and an auth
+cookie to get general information about your subscribed feeds.
+Currently, this only tells you how many new records there are since the
+last time /feed was fetched. The server will respond with a JSON
+object:
+
+
+{"new":3} ++ +
POST to /feedinfo/(user) with a username
parameter and
+an auth cookie, where (user) is a user whose subscription status you are
+interested in. The server will respond with a simple JSON object:
+
+
+{"subscribed":true} ++ +
The value of "subscribed" will be either true or false depending on +the subscription status. + +
POST to /passwd with a username
parameter and an auth
+cookie, plus password
and new_password
+parameters to change the user's password. For extra protection,
+changing a password requires sending the user's current password in the
+password
parameter. If authentication is successful and
+the password matches, the user's password is set to
+new_password
and the server responds with JSON success.
+
+If the password doesn't match, or one of password
or
+new_password
are missing, the server returns JSON failure.
+
Blërg does both by smashing 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. +application. Blërg can be run as either a standalone web server +(currently deprecated because maintaining two versions is hard), 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 @@ -362,28 +438,27 @@ until after I wrote Blërg. :)
I was impressed by varnish's design, so I decided early in the design process that I'd try out mmaped 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 +Blërg has their own database, which consists of a metdata file, and one +or more data and index files. 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. The database's limits are reasonable: +handle when to read from disk (or maybe not — I haven't +benchmarked it). 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. The database's limits are reasonable:
maximum record size | 65535 bytes |
maximum number of records per database | 264 - 1 bytes |
maximum number of records per database | 264 - 1 |
maximum number of tags per record | 1024 |