As I mentioned, to start with we’ll just pre-populate the database rather than worrying about the interface up to that point.
Birdfeeder.pl 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 Wirebird.pm 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 Wirebird.pm 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:
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).
A usergroup of one.
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
obviously I should blog less, debug more.)