I’m taking a break from shaving the nginx/node-solid yaks to… shave a different set of yaks. (SQUIRREL!)

Conversations on the solid chat and #perlrdf IRC channel have been about implementing the solid standard in Perl. KJETILK thinks that the main missing piece is OpenID Connect so, well, that’s what I’m reading up on.

The nginx/node-solid issue at this point is, I’m reasonably sure, a permissions problem. Because every Linux problem is a permissions problem. (And also because node-solid is running as me.)

I decided to stop fighting with getting nginx to reverse proxy for the which, node-solid-server and punched a hole in the firewall to talk directly to it. This made my errors a little clearer, and I realized I was still pointing to the self-signed cert I had created for single-user mode. Whoops! Turned out that wasn’t the only cert problem though, because as soon as I created a WebID I remembered that NSS does that by prepending your username and my URL was ending up something like https://gamehawk.garuda.phoenyx.net:8443/profile/card#me which, on top of being unwieldy, requires wildcarding in both cert and DNS, neither of which I have going on at the moment.

Shoving the thing into my /etc/hosts manually and clicking through Firefox’s cert complaint let me view it, but then I realized that to actually make any changes means (I think) the server is going to have to validate the WebID, which it does by connecting to itself - so it’s going to need both cert and DNS to be valid.

I think tomorrow I’ll go back to nginx, and see if I can get it to serve both static pages and NSS. If I can do that, I can install the whole shebang on the live phoenyx.net server, and do the wildcard from there.

Finished the solid install, then decided to reverse-proxy it through nginx for now so I installed that too. To get solid to properly work, it needs to be a non-self-signed cert so I installed Let’s Encrypt and… okay, I’ve read a million blog posts from people being amazed at how easy it was to install and, well, let me just add mine to the collection.

I started writing a test suite for a Linked Data Platform server, by way of getting my head around all the requirements and what they are for. Lacking an LDP server to test the test against, I started running it against solid.community and pretty quickly ran up against the wall of needing a WebID to authenticate with before actually getting any Turtle files. So logically the next thing to do was to start running a WebID server of my own.

This led to needing an Internet-accessible server, which in turn led me to decide I was going to set aside a week (or so) to install all the extant Solid tools, so I could decide how much of the wheel I wanted to reinvent and how much I could lean on existing stuff. Which led me to… install node.js.

Spoiler alert: it did not go well.

After wasting most of a day, I ranted a bit in the node-solid-server Gitter channel and learned that what I should have done was skip everything nodejs.org says and install node via nvm. Which, if you search for it, just looks like some rando’s Github package, but turns out is essential to getting all the permissions installed correctly. That’s now done, and the next step is to configure the Solid server, and then think about what I’m going to set up in the way of a WebID server. Pretty sure node-solid doesn’t handle that itself, but I guess I’ll find out… tomorrow.

It has been a week for working on Wirebird in five- and ten-minute increments, with insufficient sleep, and it shows.

I’ve never been happy with the Dancer2 server passing things to Wirebird::Resource->create() as a RDF::Trine::Model in part because I have to predeclare the subject URL of the created triples. But I didn’t want to pass the Dancer object because I didn’t want Wirebird::Resource to be Dancer-dependent (since it’s called from non-web processes already). But then I decided, good grief, I’m already overloading the $parms variable in a way-too-hacky manner. Sometimes it’s a Resource object, sometimes it’s a naked URL, sometimes it’s a Model… yeah, that’s really getting bad.

So now it’s going to accept proper named parameters, but the changeover is entirely incomplete.

In other cleanup news, I’ve fully moved Plerd to the Cruzer, and the Pi is powered down. Soon, possibly this weekend, I’ll get around to fully installing it in its little case so that it’s entirely portable. Then I can just pop the Cruzer into it as a somewhat eccentric laptop.

Today (such as it was) is just a continuation of yesterday’s work.

I have turned off static-file handling for now, ironically after changing it to write RDFJSON, RDFXML, and Turtle. Linked Data Platform, and therefore Solid, require a lot of headers and by the time those are calculated, serving the body itself dynamically is fairly trivial. That doesn’t give anything concrete for ETag to build off of though, so that will probably change back. In the meantime, it’s starting to serve some of the other LDP-compliant headers.

I also got started on the Friday cleanup early, and have begun shifting todo’s into Gitlab issues. Not sure I’ll get too committed to that, though, because I think I’d like to self-host Gitea instead.

Another day of not so much coding (after a 4am trip to the airport), but I have started cleaning up things like serving RDFJSON, RDFXML, and Turtle. While I’m at it, I might as well get around to building the rest of the headers to make it a proper Linked Data Platform arrangement, and therefore more aligned with Solid.

On which note, I’ve joined the Gitter chat rooms for Solid, which I hadn’t previously known about until the Vanity Fair article. I’m not a fan of Yet Another Chat Room, but hopefully that will fill in some of the gaps in my knowledge.

I mentioned Solid in an earlier post and have been poking through its various applications off and on. It is essentially the same principles I laid out for Wirebird in the first post so I feel kinda validated: it’s not just some kind of 2008 idea that everybody has already tried and discarded and I’m just late to the party on.

Tim Berners-Lee, Web Developer

Vanity Fair(?!) had an interview with Sir Tim yesterday, brought to my attention by Eugen after a one-hour interview with him was boiled down to, well:

One hour, one sentence

No real code changes today; it is my birthday and also the day before we ship son across the country to visit an uncle and aunt so we’ve taken a day off. But now that I more-or-less have feed polling happening, getting it serving Turtle et al is the next priority - and doing so in a solid-compliant manner.

There is a bunch of different articles out there on handling ordered lists in a triple store.

  • RDF Collections (the standard)
  • RDF Lists and SPARQL (from the author of Learning SPARQL)
  • [https://stackoverflow.com/questions/25351911/working-with-sparql-lists-in-dotnetrdf-intersection-of-lists#25369706

An ActivityStreams inbox is a streams:OrderedCollection, though after mostly getting list insertion working I ended up deciding entries should always be added to the end. (The client can decide to re-order them, but should always know which ones are newly added that way.) I preserved the other version as Inbox.pm.snippet for this commit only.

I’ve poked around looking for list handling in the RDF::Trine libraries, with little success. RDF::Trine::Parser::Turtle, for instance, has some handling because Turtle syntax can pass lists. But because RTPT just returns the triples for the parsed Turtle, rather than adding items to an existing list in an existing store, it just does the most basic iteration over the list, adding the first/rest nodes. Which is one way of handling it: just delete all the nodes and re-create them every time an item is added or removed.

Conversely, RDF::Trine::Serializer::Turtle turns triples into lists, but again doesn’t have to do any modification of the lists. RDF::Trine::Model has add_list, get_list, and remove_list; it also (wait for it…) treats lists as all-or-nothing items.

All of which means I should either start treating lists that way myself, or else think about writing an RDF::Trine/X library for lists. Only… GWILLIAMS is moving from RDF::Trine over to Attean::, which eventually (when it’s stable and documented) I also will eventually do.

In other news: ironically it isn’t the Pi’s SD card throwing errors, it’s the spinner in my desktop machine. I still picked up a cheap 32GB thumb drive at Costco, and shifted the Wirebird directories onto it… including switching to SQLite in the data directory. Now rather than sshfs-mounting the shared directory, I’m physically carrying the drive back and forth between the Pi and desktop, which is less than ideal, but I do get to see the performance difference between the Pi and the desktop. It’s interesting, but I’ll probably move the directory to the desktop machine (sshfs-mounting it the other direction) once the spinner is replaced.

It was a pretty unsatisfying week all around, at least as far as coding progress goes. I did learn a lot, at least.

I can’t believe there aren’t any shortcuts in the RDF::Trine libraries to handle ordered lists. It’s so unbelievable, in fact, that I’m pretty sure it’s there and I’ve just overlooked it. Every now and then I have to go back through the CPAN libraries and go, “oh NOW I see what that does.”

At any rate, today I did the weekly perlcritic (passing, but only at stern) and perltidy and docs test, so that’s all tidied up. Polling subscriptions is still broken, but the queries are this close to working.