Aehso’s Output

Google Reader is now using Google Gears to enable offline reading of your 2000 most recent items.  Check the top right corner of your reader for a new ‘Offline’ button to trigger installation.

Ars (and lots of other sites) have the user details, check out the Gears API Developer’s Guide for more info on the implementation.

It’d be fantastic if they did a version for Opera(or Minimo)/OS 2007/N800!

aehso atom, google, rss, web2.0

A recent discussion on rest-discuss related to describing RESTful resources has lead to interesting discussion by Aristotle Pagaltzis, Stefan Tikov and Don Box on the topic.  They highlight a couple of issues that have been bugging me (at Oisin’s expense I think!):

• How should RESTful clients bootstrap into a RESTful system, or rather, how does the client determine the correct payload to send to the first RESTful resource it interacts with?  Currently it appears that there must be some out-of-band definition of the first RESTful resource request that the client has ‘baked-in’ in order to initiate a conversation with a set of RESTful resources.  HTTP Web browsers solve this problem through (bookmarked) URLs.  Should all RESTful resource clients do the same?
• How should RESTful clients interpret arbritrary XML response payload?  The response XML is presumably defined by a schema (somewhere) but I’m wondering how is a RESTful client expected to interpret the semantics of the XML unless it has prior knowledge of the schema.  Is this prior knowledge just assumed? Again, HTML browsers succeed in this regard because they are build on the semantics of the HTML language schema.

I’d be very interested if anyone has insights into the above two questions.  If knowledge of the schema(s) is assumed (Aristotle’s post implies this) then perhaps all folks are looking for is guidance on how to determine which XML element definitions are expected/returned by RESTful resource request/reponses. 

Perhaps that’s where the value in WADL lies.  Unfortunately WADL seems to promote static resource set definitions, as WSDL does for WS-* service endpoints.  Perhaps if the WADL resource set definitions could also reference other WADL resource set definitions then we might have something a bit more dynamic?

aehso rest, soa, web services, web2.0, xml

Canola and the Media Streamer on the N800 are apparently both capable UPnP control points/players so I recently decided to set up a UPnP MediaServer on my Mac Mini, where all my media(photos/music/video) lives. I drew a blank though:

• MediaTomb – open source but I couldn’t find a universal binary anywhere.
• EyeConnect – the N800 could see the server, it did not list any available media content.
• TwonkyVision – music and photo streaming worked but I had no luck with streaming video and then the trial expired. It’s hard to justify buying commercial software when a major feature doesn’t appear to work in my environment.

Today, I notice the PS3 modders also have a list of UPnP Servers but alas nothing new there either.

Maybe I’ll have a go at building MediaTomb on OS X or maybe I’ll have to install Linux on my Mac Mini?

Update: I took the plunge and compiled and installed MediaTomb on my Mac Mini (using Apple Xcode development tools) following the instructions. There is a bit of prep work required to install the prerequisite zlib, libmagic, libjs, taglib, id3lib, libexif libraries though so this approach is not for the faint-hearted! I did hit a minor snag getting the MediaTomb configure script to use libjs v1.6 but resolved that with a little help from Jin. Streaming music and photos works great with Canola but some streamed DIVX-encoded AVI files won’t play – I’m assuming that is an N800 codec problem though…

Update 2: A day later, Jin announces that MediaTomb is now available via Fink. That should makes it easier for the rest of you to compile/install. Thanks Jin!

aehso media, n800, oss, upnp

I was trying to use Google Reader on my N800 at the weekend and it just didn’t work well enough to be usable. The page layout and text size really isn’t suited to a 800×480 display, I was scrolling far too much to reach important buttons/links and some of the AJAX controls (such as the tree nodes) just did not seem to react to touchscreen input.

However Google Mobile Reader has more than saved the day. This stripped down version of reader is designed primarily at mobile phone handset users, but it works very well on the N800.

The main page, once logged in, shows the ten most recent posts with convenient page-forward and mark-as-read-and-page-forward links:

The Subscriptions page is simplicity itself – a flat list of feeds, with feeds that contain new posts at the top of the list.

Each Feed page (http://www.google.com/reader/m/view/feed%2F<HTTP-encoded-feed-URL>) is almost as simple but with one line of the entry body under each item, and additional navigation/mark links at the bottom:

Each Entry page (as above with additional query string) is also simple, with convenient links to see the original feed entry page, along with links to star, mark as read and move to next.

Note my recurring use of the term ’simple’. In this environment, simplicity really does win the day and in this case it adds up to a very usable service. The fact that it is perfectly synchronized with my laptop feed reader is a significant plus. I left NetNewsWire behind a long time ago because I just couldn’t coordinate reading sessions across my home mac and my work pc. This is really another type of client that I want to read the same data access the same service with.

And then I noticed that they have a custom Google Reader for the Wii too, with bonus Wiimote integration! It is going to take a lot to get me to ever switch to a different feed reader.

aehso atom, google, n800, rest, rss, web2.0

I see irishelection.com have a big stonking MySay election count widget on their home page and it is looks to be working extremely well. Kudos to SOS and the boys at MySay, this really is excellent!

aehso irish

If you’re looking for a 100% electric car you could do worse than reserve a Tesla Roadster.

Sweet.

aehso cars

Interesting comment by James Clark in his first blog post on the topic of weaknesses in the current XML/XSD data binding solutions when used to encode remote message payload:

This pain is experienced most sharply at the moment in the SOAP world, because the big commercial players have made a serious investment in trying to produce tools that work for the average developer. But I believe the REST world has basically the same problem: it’s not really feeling the pain at the moment because REST solutions are mostly created by relatively elite developers who are comfortable dealing with XML directly.

It is an interesting observation, and it highlights yet again that the lack of appropriate tooling is a major barrier to development of large-scale REST solutions. I am undecided still about what effective tooling would look like (over a year after I asked where is it?) but I am sure it has to be no more complex to use than a browser. I’m not sure if a thick client IDE is even appropriate, given the nature of the solution being developed.

One thing that I think is obvious now is that the difference between true RESTful solutions and XML/HTTP-binding based web service solutions has become somewhat blurred. Perhaps we have the prevalence of XML/HTTP WSDL bindings to thank for that. Also, the recent arrival of WADL, and its use by tooling with names like REST Describe may also be playing some part in the notion that one can capture the interface of true RESTful solution in static header files. But some tooling is better than none and I look forward to getting a better grip on this space.

I was curious about what has been going on in JSR-311 (RESTful Web Services) but this doesn’t bode well – I’ll reserve judgment until after I’ve read the draft. (Wouldn’t it be great if JSR working groups were more transparent?)

aehso rest, web services

Glassfish V3 introduces a new kernel, HK2 (Hundred Kb Kernel) , that has yet another modules model. An interesting statement on the H2K home page is tantalizing:

Modern Java software usually rely on a module subsystem to offer a better level of isolation between parts of the application. Many technologies have been around for years, HK2 proposes a model which is aimed to be friendly to existing technologies such as OSGi yet will provide a path to the implementation of modules in Java SE 7.

Scant details on the OSGi integration/adaptation layer so far, but it’ll be interesting to see how this one pans out…

aehso java, osgi