Re: [pcp] sketch of possible web pmapi

[Ben Birch <bbirch@aconex.com>]

Hi All,

  So as Paul has indicated, I'm the developer of a elasticsearch-head, which is an admin interface built on top of a RESTful api serving json. In the past I have worked with an xml -> xslt -> website build.

Sorry for top posting, but I wanted to give an overview opinion rather than address individual points.

For something like the pmapi, really a RESTful interface is the way to go. If you accept this, you really don't want a RESTful api serving xslt (or even serving something that looks good in a browser), it conflates a pure data interface with presentational features that most consumers of your api are not interested in.

Now whether you serve XML or JSON is largely a decision based on who your likely consumers are. There does seem to be a swing away from xml to json, but I'm a ui engineer - so I might be biased. Certainly languages like java and python have json support that is as good as xml. JSON - which is a subset of a programming language - is more suitable for use IN programming languages (explicit support for boolean/numbers/arrays/maps) - where as xml is really a generalised document markup langauge. However if your primary goal is a static website, and you have xslt skills it might be a good choice!

Luckily this is not a choice you must make, as there are frameworks that help you write RESTful interfaces which will allow the consumer to choose XML or JSON (literally by appending ?format=xml or ?format=json ).

If you are worried about serving a basic website out of the box, you might consider starting two services
eg http://localhost:9100 is the website
   http://localhost:9101 is the rest api ?

Regarding js development: most front end engineer are going to be looking for a json api, since json can be directly pushed into rich interface frameworks. Most api consumers are likely to be java/phython/etc apps who can generally use xml or json interchangably, or web apps which have javascript available.
 
----

For an example of the kind of code I'm writing to display tablular data (the actual table templates are in a kind of third party library)

onDataReady: function(metadata) {
    this.metadata = metadata;
    this.dataSource = new es.QueryDataSourceInterface( { metadata: metadata, query: this.query } );
    this.resultTable = new es.ui.Table( {
      onHeaderClick: this._changeSort_handler,
      store: this.dataSource 
    } );
    this.resultTable.appendTo( this.el.find("> .browser-table") );
    this.updateResults();
}

not sure if this is illustrative though. As far as xslt vs javascript being easier to program - it's really not a fair comparison because all you can do with xslt is produce html, where as for the same effort javascript gives you an interactive web app. (actually I found xslt always gave me headaches... )


Cheers,

-Ben



----- Original Message -----
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>
Sent: Thursday, 24 March, 2011 1:23:29 PM
Subject: Re: [pcp] sketch of possible web pmapi


> 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