Re: [pcp] sketch of possible web pmapi

[Paul Smith <psmith at aconex dot com>]

On 24/03/2011, at 1:08 PM, Frank Ch. Eigler wrote:

> Hi, Paul -
> 
>> I'm not sure of the use case of viewing HTML these days with a
>> browser that doesn't have javascript accessible though.. ?
> 
> It's not just the browser, but other basic html consumers like web
> spiders.  Plus on browsers too, security worries often mean lockdown
> of javascript.  Plus it's a possible milestone for development: to get
> something browseable & barely usable, before having to hack on
> javascript.
> 

Not 100% sure what the web-spider use case is about..?  Could you describe that more?  With regards to disabling javascript on browsers in security concious environments would render many useful tools for production-like activities that would be rendered difficult there.  

A very basic javascript pattern to click->drill into is exceedingly simple though?

>> yes, different formatters could be selected, although that adds
>> complexity.  XSLT is just.. well... a fairly 'dead' platform these
>> days.  Sure, still used, just if something is being done new here, I
>> would think worth considering what the state of play of the browsers
>> support for things?
> 
> Yeah.
> 
>> Rendering a HTML table for example when the JSON is actually pretty
>> readable by a human already (certainly compared with XML).
> 
> Yes, but a human-readable piece of text isn't clickable in the way
> an html table with <A>'s in 

can be done with css/javascript in the same time or less than XSLT I think.  

> 
>> One thing I don't like about embedding XSLT details in the XML
>> output is that it is still coupling the presentation layer to the
>> data delivery layer here.
> 
> I see what you mean, but if we are to generate something
> html-renderable at some point, we'd have to provide a default
> presentation layer somehow.
> 

I agree they can't be done in isolation, I just do think they should be separated concerns.  Ben how much effort was the ES clickable JSON stuff?  Is there a basic example you can show us from elasticsearch-head?

>> I would have thought much better to design the REST or whatever
>> mechanism so that it is purely a cross platform data delivery
>> platform that both simple browsers and other application clients can
>> interact with.
> 
> I figured that a more sophisticated use than the dumb html browser
> would be able to suck out the exact raw xml data by simply skipping
> the xslt transform.  It's this dual-use aspect that seems to make xml
> attractive here.  With JSON, we get reasonably easy human eyeballing,
> and machine parsing, but not the simple html case.  (And with the html
> rendering, human eyeballing of the raw message may not be that
> important anyway.)  I don't know what the best answer is though.
> 

But you still have to develop the XSLT transform.  That's not difficult sure, but then it's probably the same as the css/javascript 'viewer'.  I'm totally happy to volunteer my time on that, actually I'm more likely to volunteer Ben's time on that.. :)

At the end of the day though this is driven by the community and what people want.  I'm just proposing JSON as a nice lightweight simple output that humans and code both like, together with choosing something that has good mainstream support now compared with something that is rapidly withering away as a common technology of use.

There's a lot more power and potential in the JSON/JavaScript for a 'client' application of this REST/whatever API.  Charts, drill throughs, tabular views with frameworks like jQuery/ExtJS etc.

Paul