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
|