This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: http/xml bridge for web-based pcp clients


----- "Frank Ch. Eigler" <fche@redhat.com> wrote:

> Hi -
> 
> Eventually, it'd be nice if a java/javascript type web application
> could suck data out of a PCP installation and present it in glorious
> HTML.  This should include normal metric access as well as the new
> event stuff from 3.5.0.  The key missing link right now seems to be a
> web-accessible interface.  (nathans' json-pcp work, to the extent I
> understand it, is not directly responsive to this need.)

Yes, not directly ... there was some hand-waving involved around the
lines of an apache plugin to do the http side of things and hand off
work to pmproxy, but didn't get that far.

Definitely agree this is a missing piece of the puzzle still, would
love to see something (small & fast) in this space.

> The smallest new piece of code that seems to accomplish the need
> would
> be a mini http server that speaks a xmlrpc-ish version of the PMAPI.
> It'd be like a pminfo-over-http.  One extension would be that a
> single
> pcp client connection would be reused for the duration of a web
> "session", consisting of many independent xmlrpc calls.
> 
> As for implementation details, something like libmicrohttpd [1] for
> the protocol level stuff; or perhaps XML-RPC [2] and its abyss http
> code for http server side support; plain vanilla LGPL C code for the
> glue between that and PMAPI.
> 
> Does this sound sensible?

>From the json pmproxy translator experiment, I'd say we can learn:
- fair bit of work involved in translating every PCP PDU, this is
probably too low a level for javascript clients.
- the connection statefulness (or lack thereof) is a problem - I'd
tried to have no new state in pmproxy, but it falls down in some
places, like on profile+fetch PDUs IIRC.
- worse still, http/javascript clients are unlikely to keep the
socket connection open, so some form of session state must be kept
there in the end and not clear whether the connection to pmcd can
be dropped and reestablished without extra state on the server.

cheers.

-- 
Nathan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]