On my birthday last year I wrote up a snapshot of what was happening in my life. A year has flown by and so here’s this years snapshot. Warning navel gazing commences…
Another great article from Sean McGrath: The mysteries of flexible software. Bang on the money.
I don’t know how many times I’ve encounted software (and yes, some of my own devising) that has all sorts of wonderful flexibility but in all the wrong places. Time spent factoring applications into layer cakes, introducing endless layers of abstraction may have some benefits, but exactly how often do you go through an application and rip out the entire persistence layer? And when you do, what’s the biggest hurdle: changing the code, or the data migration and testing involved to guarantee that you’ve not broken any of the data integrity? Exactly how often do you swap in and out XML parsers and XSLT engines?
I’ve been a keen advocate of design patterns for some time, but it’s easy to get carried away: achieving a particular design pattern (or set of patterns) becomes a requirement in itself and that in all likelihood isn’t going to affect the success of a product. The “Just Do It” aspect to XP is one obvious reaction to that experience. Renewed interest in more flexible, easy to author languages like Python is perhaps another.
Abstraction ought to be a defense mechanism. If a particular area of code or functionality is continually under change, then introduce some abstraction to help manage that change. Trust your ability to refactor. Don’t over architect too early.
I’ve been skimming through the info URI scheme RFC. From the Cover Pages we learn that the scheme “was developed within the library and publishing communities to expedite the referencing by URIs of information assets that have identifiers in public namespaces but have no representation within the URI allocation.“.
We also learn that “The motivation behind developing the info URI scheme is “to allow legacy identification systems to become part of the Web global information architecture so that the information assets they identify can be referenced by Web-based description technologies such as XLink, RDF, or Topic Maps. The scheme is concerned with ‘information assets’, not ‘digital assets’ per se, so the information assets may be variously digital, physical or conceptual.”“.
I’m trying to get my head around why it’s necessary to have a new URI scheme for this purpose — why not use a URN or an HTTP URI? For further discussion on that we have to look at “Section 7 Rationale” of the RFC.
One main reason seems to be passed on a desire to avoid any expectation of dereferencing semantics. Info scheme URIs cannot be dereferenced, they are for identification only. So the reason for not using an HTTP URI is because they can be dereferenced; one reason for not using a URN is because they’re encouraged to have a mapping to a dereferencable form.
Another reason for not using a URN is persistence of the identifier. A URN is supposed to be a stable identifier for a resource, but an info URI has no claims to stability. To be precise: “The “info” URI scheme is neutral with respect to identifier persistence”
Unfortunately I’m still none the wiser to the actual benefits here. It seems that the info scheme gives me a non-deferencable, and in all likelihood non-stable identifier for a resource. Um, doesn’t that give us the worst possible scenario?
Being able to dereference a URI is an important quality IMO; and thats one reason I like RDDL. If I can do a GET request and get the resource, or some metadata then that resource is bound into the web infrastructure. If the location isn’t stable then following HTTP 3XX codes can lead me to the correct location. Redirection is one of the client-server co-ordination mechanisms that’s built into the guts of the web, why not use it?
More discussion on info URIs here.
I’ve not encounted a URI discussion that doesn’t have all sorts of hidden complexities so no doubt I’m missing something. Anyone else see any strong benefits of having a new scheme here?
Passing on a meme I caught from Norman Walsh. The fifth sentence on page 23 of The Diamond Age by Neal Stephenson is:
But while Lord Finkle-McGraw was not the sort to express feelings promiscuously, he gave the impression of being nearly satisfied with the way the conversation was going.
This isn’t the book I’m reading, that’s Foucault’s Pendulum, this was just on my desk in work as I’ve recently lent it to a colleague.
The W3C have posted a Note discussing requirements for an XML Processing Model. This is good news, there’s been a lot of desire to see this work progressing for some time now. Wonder whether XML Pipeline will serve as a possible basis for a specification? It seems to be a good match to the requirements.
It’ll be interesting to see how this ties in with the DSDL work which is essentially defining a validation oriented processing framework. Frustratingly there’s been little updates to the DSDL web site to see how far they’ve progressed. This xmlhack report seems to have the most recent summary of activities. Please update your site DSDL people!
I’ve been thinking about writing some Jabber services or bots recently as we’ve been trialling a Jabber server at work as a replacement for the myriad different messaging services folk are now using.
I’ve been hunting round, unsuccessfully I might add, for something as easy to work with as PircBot a Java IRC Bot framework. Not that it has to be Java as I’ve been making baby steps towards learning Python.
Anyway whilst leafing through my copy of Programming Jabber I started thinking about Jabber’s extensibility and its use as an asychronous messaging component in a service framework. How might that be integrated with people-centric, desktop applications? And then I thought about Dashboard.
In the Dashboard architecture, cluepackets are used to send messages between front and back-end applications. Now what if there was a way to tunnely cluepackets through Jabber? Has someone explored this already?
There are some interesting possibilities here. Your front-end application may be talking to a backend on my desktop, e.g. whilst you’re browsing for new music a cluepacket may ultimately get routed to my local backend (RDF backed, naturally) which can respond with my reviews and recommendations.
Tie this in with buddy lists and you’ve got a neat way to mine a community (your community of friends and colleagues) for data without having to index it all in advance. For example it could be used to pull together calendar data so you can co-ordinate a trip with your friends.
There’s a Music Metadata Summit today at Stanford Law School. There’s a conference “back channel” via #musicmetadata on freenode if, like me, you are geographically challenged.
Some interesting topics in there and a lot of overlap with FOAF (tipjars, playlists, recommendations, etc).
I’ll probably be dropping in on the IRC channel later this evening.
The AudioScrobbler folk are thinking very hard about scalability. Having recently switched to a new database server they’re now pondering what other changes they may need to make to ensure that the service scales as smoothly as possible.
In this posting to the audioscrobbler-development list Richard Jones outlines some proposed options. It seems that they’ve already tuned the database server and are considering changes to the submission protocol, the means by which your MP3 player submits track info.
The most fundamental change to the protocol, which is further described in the AudioScrobbler Wiki, is to do more on the client. Each client would hold it’s own database of track information and then intermittently upload data, based on a interval controlled by the server. In the existing model data is POSTed to the server after a track is ~50% of the way through.
Personally I think the protocol could be adapted to be more RESTful. The key thing being to make each user account a resource which can have information requested from it (GET) or updated (POST). Making more use of GET ought to help scalability as caching intermediaries can better do their thing.
This would make an good optimisation/design exercise for RESTafarians to get involved with. Comments should be added to the Wiki or sent back to the mailing list.
Update: I posted a suggestion for an alternative interface which I think is more RESTful. I’d love to get this critiqued (hint, hint!)
Liam Quinn wrote an adventure game using RDF (data). Found via the SWIG chump, and noted here so I can find it again in the future.
I was reminded of it after stumbling across Inform a design system for interactive fiction that’s been around since 1993.
Since its invention…Inform has been used to design some hundreds of works of interactive fiction, in eight languages…It accounts for around ten thousand postings per year to Internet newsgroups. Commercially, Inform has been used as a multimedia games prototyping tool. Academically, it has turned up in syllabuses and seminars from computer science to theoretical architecture…
This is exactly the sort of thing that could be a huge time sink for me. I used to spend vast amounts of time playing, designing and running role-playing games. No surprise there huh?!
Apparently Inform is based on a world model and accompanying rule system that deals with “rooms, items, vehicles, duplicates, containers, doors, things on top of other things, light and darkness, switching things on and off, opening, closing and locking things, looking up information in books, entering things, scoring and much more”.
I’ve always been a frustrated game designer, that’s why I used to spend a great deal of time on this project. Maybe there’s still time. Text based adventure gaming is still all the rage isn’t it?