From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29886 invoked by alias); 24 Mar 2011 06:11:17 -0000 Received: (qmail 29876 invoked by uid 22791); 24 Mar 2011 06:11:15 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_WEB,TW_JS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.aconex.com (HELO postoffice2.aconex.com) (203.166.49.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Mar 2011 06:11:09 +0000 X-ASG-Debug-ID: 1300947066-0157b414417c090001-x9Qv3j Received: from postoffice.aconex.com (postoffice.yarra.acx [192.168.35.100]) by postoffice2.aconex.com with ESMTP id Y1l6K6OaLCpGhGlC; Thu, 24 Mar 2011 17:11:06 +1100 (EST) X-Barracuda-Envelope-From: bbirch@aconex.com Received: from gatekeeper.aconex.com (gatekeeper.yarra.acx [192.168.35.102]) by postoffice.aconex.com (Postfix) with ESMTP id A8453A505FA; Thu, 24 Mar 2011 17:11:06 +1100 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by gatekeeper.aconex.com (Postfix) with ESMTP id 21A569D000C; Thu, 24 Mar 2011 16:51:49 +1100 (EST) Received: from gatekeeper.aconex.com ([127.0.0.1]) by localhost (gatekeeper.aconex.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76am4sFzKFIa; Thu, 24 Mar 2011 16:51:48 +1100 (EST) Received: from acxmail-au2.aconex.com (acxmail-au2.aconex.com [192.168.35.104]) by gatekeeper.aconex.com (Postfix) with ESMTP id 62A5C9D0004; Thu, 24 Mar 2011 16:51:48 +1100 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by acxmail-au2.aconex.com (Postfix) with ESMTP id D83D83B20002; Thu, 24 Mar 2011 17:11:05 +1100 (EST) Received: from acxmail-au2.aconex.com ([127.0.0.1]) by localhost (acxmail-au2.aconex.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l2kAlStpNtn; Thu, 24 Mar 2011 17:11:05 +1100 (EST) Received: from acxmail-au2.aconex.com (acxmail-au2.aconex.com [192.168.35.104]) by acxmail-au2.aconex.com (Postfix) with ESMTP id BF5E93B20001; Thu, 24 Mar 2011 17:11:05 +1100 (EST) Date: Thu, 24 Mar 2011 06:11:00 -0000 From: Ben Birch To: Paul Smith Cc: pcp@oss.sgi.com, systemtap@sourceware.org, "Frank Ch. Eigler" Message-ID: <1593492084.6281.1300947065694.JavaMail.root@acxmail-au2.aconex.com> In-Reply-To: Subject: Re: [pcp] sketch of possible web pmapi MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] sketch of possible web pmapi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: postoffice.yarra.acx[192.168.35.100] X-Barracuda-Start-Time: 1300947066 X-Barracuda-URL: http://postoffice2.aconex.com:8000/cgi-mod/mark.cgi X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -0.39 X-Barracuda-Spam-Status: No, SCORE=-0.39 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, CN_BODY_332, WEIRD_PORT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.58804 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 1.50 WEIRD_PORT URI: Uses non-standard port number for HTTP 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2011-q1/txt/msg00524.txt.bz2 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" To: "Frank Ch. Eigler" Cc: pcp@oss.sgi.com, systemtap@sourceware.org, "Ben Birch" 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 '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