Technology, Books and Other Neat Stuff

Molesworth meets Potter. Hello sky, hello clouds, hello Prof. Snipe.

...amongst one group of UK LJ'ers... is finally getting round to embedding our LJ's in our personal web sites. While I used a standard perl script for my test, codepope has produced a nifty bit of JavaScript code for his site.

Now all I need to do is design a basic theme for my LJ, and then move the code from my test space to the main site... So, I guess that'll take me another few months!

One of regular visits to Boing Boing turned up this site. Feed it ASCII and you get a barcode. So here I am...



So now I can scan myself at Sainsburys or Waitrose.

Or at least on a Pocket PC 2002 device like my Jornada. Download PocketFeed here.

However, I think this is something best done server side and delivered via AvantGo or something similar. Still, I'll give it a try for a while and will see what happens. You never know, I may end up a convert. For one thing it's playing to the Pocket PC strengths as a smart device.

I finally got round to reading Doc Searls' presentation from O'Reilly's OSCON on infrastructure and its role in supporting culture. It's an interesting take on how cultural forces are both ubiquitous and invisible.

It's nice to see someone put into a slide deck what I'm thinking about. This is what I'm thinking about when I talk about the role of ubiquitous and context computing in the next generation of service architectures, and what I'm trying to drive at by defining publish and subscribe web services. It's what I was trying to do when I sold a Portuguese 3G operator on the idea of providing the infrastructure to drive services instead of just providing a content pipeline (and that's probably why I didn't get the job at Hutchison 3G, seeing as it was for a DRM architect...).

What I suggested to them was that they did what they did best, providing a UI layer for the devices they supported, and a generic workflow language, along with the wireless network. They would also manage a directory of service components (using open web services standards). Developers would select components, and tie them together with context-based workflow, as well as adding new components to the library, allowing further refinement of the model. The only rule would be: once you define an interface for a component it will be fixed. That way components would always be available - though they could be improved and extended. And they could be built on any platform that supported web services - from Java to .NET.

I've finally found somewhere to publish the book chapter I wrote on the ideas behind the web services infrastructure model I came up with (and there's another piece on it here). Now to spread the word further.

(Note: some links here go straight to PDFs of articles)