<li><a href="#api_subscribe">/subscribe/(user) - Subscribe to a user's updates</a></li>
<li><a href="#api_unsubscribe">/unsubscribe/(user) - Unsubscribe from a user's updates</a></li>
<li><a href="#api_feed">/feed - Get updates for subscribed users</a></li>
- <li><a href="#api_feedinfo">/feedinfo/(user) - Get subscription status for a user</a></li>
+ <li><a href="#api_feedinfo">/feedinfo, /feedinfo/(user) - Get subscription status</a></li>
+ <li><a href="#api_passwd">/passwd - Change a user's password</a></li>
</ul>
</li>
<li><a href="#design">Design</a>
<h3><a name="configuring">Configuring</a></h3>
-<p>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.
+<p>There is now an experimental autoconf build system. If you run
+<code>add-autoconf</code>, it'll do the magic and create a
+<code>configure</code> 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.
+
+<p>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.
<p>Also, further apologies to BSD folks — I've probably committed
several unconscious Linux-isms. It would not surprise me if the
the prerequisites for <code>blerg.httpd</code> or
<code>blerg.cgi</code>.
+<p><strong>NOTE</strong>: blerg.httpd is deprecated and will not be
+updated with new features.
+
<h3><a name="installing">Installing</a></h3>
<p>While it's not strictly required, Blërg will be easier to set up if
<p>POST to /feed, with a <code>username</code> 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.
+from all subscribed users, in reverse chronological order. Fetching
+/feed resets the new message count returned from /feedinfo.
<p>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.
-<h3><a name="api_feedinfo">/feedinfo/(user)</a> - Get subscription
+<h3><a name="api_feedinfo">/feedinfo, /feedinfo/(user)</a> - Get subscription
status for a user</a></h3>
+<p>POST to /feedinfo with a <code>username</code> 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:
+
+<pre>
+{"new":3}
+</pre>
+
<p>POST to /feedinfo/(user) with a <code>username</code> 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:
<p>The value of "subscribed" will be either true or false depending on
the subscription status.
+<h3><a name="api_passwd">/passwd</a> - Change a user's password</a></h3>
+
+<p>POST to /passwd with a <code>username</code> parameter and an auth
+cookie, plus <code>password</code> and <code>new_password</code>
+parameters to change the user's password. For extra protection,
+changing a password requires sending the user's current password in the
+<code>password</code> parameter. If authentication is successful and
+the password matches, the user's password is set to
+<code>new_password</code> and the server responds with JSON success.
+
+If the password doesn't match, or one of <code>password</code> or
+<code>new_password</code> are missing, the server returns JSON failure.
+
<h2><a name="design">Design</a></h2>
<h3><a name="motivation">Motivation</a></h3>