From: Paul Smith <psmith@aconex.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: pcp@oss.sgi.com, systemtap@sourceware.org, Ben Birch <bbirch@aconex.com>
Subject: Re: [pcp] sketch of possible web pmapi
Date: Thu, 24 Mar 2011 02:23:00 -0000 [thread overview]
Message-ID: <C7DB9B5D-31F6-45FB-AD0F-1B658A570CA1@aconex.com> (raw)
In-Reply-To: <20110324020859.GB4401@redhat.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
next prev parent reply other threads:[~2011-03-24 2:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-22 17:54 Frank Ch. Eigler
2011-03-22 23:03 ` [pcp] " Paul Smith
2011-03-23 3:58 ` Frank Ch. Eigler
2011-03-23 4:28 ` Paul Smith
2011-03-24 2:09 ` Frank Ch. Eigler
2011-03-24 2:23 ` Paul Smith [this message]
2011-03-24 6:11 ` Ben Birch
2011-03-25 1:26 ` Frank Ch. Eigler
2011-03-23 21:41 ` Nathan Scott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C7DB9B5D-31F6-45FB-AD0F-1B658A570CA1@aconex.com \
--to=psmith@aconex.com \
--cc=bbirch@aconex.com \
--cc=fche@redhat.com \
--cc=pcp@oss.sgi.com \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).