ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tammo van Lessen <tvanles...@gmail.com>
Subject Re: [gsoc] Monitoring Console / Architecture
Date Tue, 13 May 2008 21:19:35 GMT
Assaf Arkin wrote:
>> And for the XML allergic (count me in) I Abdera has a JSON
>> representation as well.
>> Then for the view, I'm sure there are some JS Atom readers that would also
>> help a lot (I know JFeed for JQuery, dunno if there's one for prototype).
>> So
>> standardizing on Atom would also help us there. Everybody knows how to
>> render an Atom feed these days.
> Yes, but I'm not convinced rendering a JSON feed would do our end-users any
> good.  Anyone interested in reading JSON?
> Most people would prefer a nicely styled HTML page, so now that JSON has to
> be converted into HTML on the client-side.  Or you could just send HTML
> directly from the server (for the buzzword inclined, it's called AJAH).

Anyone interested in reading Atom? Probably not. That's why I suggested 
to have 2 representations of the same resource. The resource contains 
always the same information, rendered as different representations for 
different audiences. For humans, the HTML representation is best, for 
Atom clients the Atom representation. One URI fits all, so the SWT GUI 
could use the same entry point as others via a web browser. This is on 
the abstract level. On the detail level there may be some pitfalls as 
browsers don't support PUT and DELETE, so there is some JS needed to 
emulate these verbs via POSTs.
In general, this is not mixing up APIs with UIs. This is actually a 
unified API for different audiences, i.e. people and machines and that's 
what IMO content negotiation is about.

Nevertheless I'm of course fine with having a JS application separately 
that simply uses the API. In this case I'd opt for a JSON representation 
as these snippets can be directly processed in JS without a need for 
parsing, data model etc.


View raw message