Seki Update

tl;dr : three steps forward, two steps back

What?

Seki is my current pet project, a work-in-progress. Depending on perspective and level of optimism it’s either a node.js replacement for my previous blogging engine, a piece of Linked Data middleware or a Semantic Web application framework. The one possibly novel aspect is that it uses a potentially remote SPARQL store (yes, being able to address multiple stores is also on the list). Very loosely-coupled. My immediate priority app-wise is for it to work as a basic CMS (i.e. read/write content, user auth & management etc.).

Recently…

I’ve spent a fair bit of time coding on it in recent weeks, but on the surface there’s absolutely nothing to show for that. The main issue was it turning into spaghetti code, so I’ve been trying to rationalize the architecture.

Nest of Vipers

The cause of this was that one of the requirements I’m pretty firm on is supporting a variety of (HTTP-based) interfaces. So for virtually all HTTP methods I want create/read/update/delete supported wherever possible with:

• HTML (with RDFa as available) + form-encoded POSTing
• JSON (JSON-LD primarily, though I may well add more ad hoc support)
• Turtle
• SPARQL
• Text, image blobs etc.

On top of that I want to support a variety of functionality – that’ll be partitioned via parts of the URL path. Basically that means lots of variables on both the input and output. 

Templates FTW

I’m sure there are alternatives, but the easiest way of handling comms with the SPARQL server seemed to be templating on queries and results. With that in place it was obvious to follow (mostly) the same approach when handling other I/O. So add template selection to the variables mix. (I’m currently using freemarker.js templates, mostly because I used them a bit around Apache Stanbol, though tempted to change to something better known around node.js like underscore templates but there’s no pressing need right now).

Rules Rule

Guess what, a multitude of clumsily interwoven IF…THENs and quite a bit of duplicate code was the net result. I had a brief look at available libs for filtering/dispatching but didn’t find really suitable. Around the same time I encountered the nools rules engine (very nice JS with rules DSL, uses a Rete engine) and couldn’t resist trying that – after all, part of my motivation here is to have fun 🙂

It did occur to me that I could use RDF+SPARQL  (perhaps on a local in-memory store) for things like the routing rules – it is after all just down to pattern matching. For now though I’ll see how I get on with nools. It does require expressing the routes in a declarative form, so it shouldn’t be difficult to recycle later if need be. (I’m also intrigued by the potential of using nools as a reasoning engine over the RDF – thence shifting the declarative stuff over to RDF tooling that way).

Another justification for a rules engine is that I also need authentication & access control (I have put together a model for this I’m happy with, implementation shouldn’t be too difficult). That’s yet another layer of potentially twisty wiring.

Disentanglement

So recently I’ve mostly been refactoring/rebuilding to do the routing and template selection via rules in nools. Of necessity, to keep sight of what I’m trying to achieve, I had to start writing tests. Functional tests calling a HTTP client were needed. To simplify that I’ve concurrently started writing a bunch of helper classes – effectively a client API no less – which may well come in handy elsewhere later.

Do I sound like a proper developer yet?

So by default now I’ve pretty much shifted toward (functional) Test-Driven Development for the server-side bits (using nodeunit). Must look into something similar for the in-browser bits.

Oh yeah, plus jQuery

A secondary problem was that the UI pieces I’d been using (VIE/Create.js) were making me feel like I was committing too much to a framework that didn’t really offer me much. No crit intended for that work, it’s great stuff, only that the bits I need I can more easily build myself customised to this project (I am still using one artifact from over there, the delightfully minimal WYSIWYG Hallo.js editor).

Coming soon!

So my upcoming dev path is more-or-less:

• refactor existing functionality to be rule-based
• add missing CMS content handling bits (HTTP API – rules & templates for all the variables mentioned above)
• implement user management (auth & access control-related rules & templates)
• make UIs for all the above
• docs (always in-progress, but this would be a good point to catch up)
• start using it – dogfood!
• make it solid enough for production release – and release properly
• add quick & dirty other stuff (my potential app scenario list is long, starting with making semwebby clones of things like delicious, twitter, workflowy etc. I also want a semwebby personal project management tool asap)
• refactor to make mighty pluggable
• invade Poland

Chances are I’ll also get distracted by shiny things along the way. Better get some work-work done soon too…