From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20918 invoked by alias); 24 Mar 2011 02:09:28 -0000 Received: (qmail 20910 invoked by uid 22791); 24 Mar 2011 02:09:27 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Mar 2011 02:09:16 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2O291HW023448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Mar 2011 22:09:01 -0400 Received: from fche.csb (vpn-8-169.rdu.redhat.com [10.11.8.169]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p2O290kC004454; Wed, 23 Mar 2011 22:09:00 -0400 Received: by fche.csb (Postfix, from userid 2569) id 178A258154; Wed, 23 Mar 2011 22:08:59 -0400 (EDT) Date: Thu, 24 Mar 2011 02:09:00 -0000 From: "Frank Ch. Eigler" To: Paul Smith Cc: pcp@oss.sgi.com, systemtap@sourceware.org, Ben Birch Subject: Re: [pcp] sketch of possible web pmapi Message-ID: <20110324020859.GB4401@redhat.com> References: <20110322175345.GH13236@redhat.com> <6FF2157A-0696-4DFE-AAAC-86EA22292452@aconex.com> <20110323035749.GA30308@redhat.com> <1895102A-B8E6-4ADB-A946-B5A5A2963760@aconex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1895102A-B8E6-4ADB-A946-B5A5A2963760@aconex.com> User-Agent: Mutt/1.4.2.2i 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/msg00521.txt.bz2 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. > 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 > 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 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. > [...] so basically the contextName is a unique session handle > between the browser client and the RPC bridge? Yes. > [...] I guess having an implicit default value [for the > poll-timeout configured on the RPC bridge if the client chooses to > not provide one for safety? Certainly, good idea. - FChE