As I mentioned, to start with we’ll just pre-populate the database rather than worrying about the interface up to that point. is the script that will prepack the database. It doesn’t create the database; that’s a generic Postgres database that has had RDF::Trine::Store::DBI do a new() on. Which, yeah, should really be in either the script or in itself.

Anyway, it’s a hacky little script that does some very, very minimal error catching and debugging, but until there’s real validation happening inside it really doesn’t matter.

Birdfeeder makes a site root page, a usergroup page, a user, an inbox, an outbox, and a subscriptionlist. Since I don’t have a front end going, the templates for those page types have some generic html forms on them. All we really care about right now is that the subscription page has a form where you can post an url to the subscription page. (The form could be anywhere, but KISS for now.)

The templates are pretty utilitarian, designed to give me as much debug info as possible rather than to look like the finished project. Over in the sidebar is the JSON representation of the data. Here’s the site root:

Screenshot of demo site root

Again, for a single-user site this would probably be a control panel, or maybe even just the Inbox directly. This installation has auto-populated itself from the machine name (habrok) and my username (silver).

Screenshot of demo site usergroup

A usergroup of one.

Screenshot of demo site user

It leads to a lot of pointless nesting when every URI is an actual URL and there’s only one user, but obviously you wouldn’t need to navigate your way down; the top page can (just via templates) display the inbox or whatever else we want, and that’s without even layering a Javascript client on top.

Screenshot of demo site subscription page

Birdfeeder just directly calls the putPage() function, which gets called (after some authen and preliminary authz) by the Dancer app. If the validation was all in place, this would literally be all that’s required for the minimum viability I described in the first post: it’s a server that servers and accepts structured JSON (only, so far) RESTfully. Granted, this offloads a lot onto the as-yet-imaginary client, but there are standards, and they work.

(I mean, if they’re properly implemented they work. Currently Wirebird cheerfully responds to that form submission with a simple 1 so obviously I should blog less, debug more.)

Comment? Email it to me. (I'll assume I can publish it unless you say otherwise)

Next post: Subscribing to something

Previous post: Coding out loud: the Wirebird base library