Re: [pcp] sketch of possible web pmapi

[Paul Smith <psmith at aconex dot com>]

> 
> My main interest in using XML for the raw output is the ability to
> easily associate it with an XSLT stylesheet to render the data into
> HTML.  I believe that it would be useful to be able to perform basic
> navigation over the PCP data with nothing other than a plain old web
> browser or spider, even without javascript.
> 

I'm not sure of the use case of viewing HTML these days with a browser that doesn't have javascript accessible though.. ?    

> JSON could be an alternative output format, selected with some URL
> parameter.  OTOH then HTML could be the same thing.
> 


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?

Rendering a HTML table for example when the JSON is actually pretty readable by a human already (certainly compared with XML).

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.  It would make it simple for browser to auto-display things, but it also fixes the browser to one XSLT based on the output defined there.  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.    Honestly, I wonder whether the PMDAs themselves shouldn't expose REST direct ??   (that's a way bigger change though obviously, nice to have a translation layer here bridging the pmda's like pmproxy does).


> 
>>>      /context?local
>>>      /context?hostname=HOSTNAME
>>>      /context?archivefile=FILENAME
>>>                      ?poll-timeout=SECONDS
>>>      /context/CONTEXT/copy
>>> 
> 
>> Following REST pattern (see wiki pattern above), this should be a
>> POST.  The 'get' bits after the query string I believe are still
>> valid (although traditionally odd for POST, most people still do
>> that ).
> 
> (I have no informed opinion on this.)
> 
>> To add more clarity here to make sure I'm following things
>> correctly, I'm presuming the above Create Context action would
>> require a '?...&contextName=foo' [...]
> 
> Actually, I was thinking that the server process would assign an
> opaque context name, since it's the one in position to make a unique
> one.
> 

so basically the contextName is a unique session handle between the browser client and the RPC bridge?

> 
>>> - list/describe metrics
>>> 
>>>      /context/CONTEXT/metric?glob=GLOB
>>>      /context/CONTEXT/metric?pmids=ID1,ID2,ID3
> 
>> Following the REST pattern again, and stealing liberally from the
>> way ElasticSearch does this, I would suggest:
>> 
>> /context/{contextname}/_metric?glob=...
> 
> Are you only proposing to prefix the listing-type operations with an
> underscore, or is there something else?
> 

yes, it's a RESTful pattern here seperating the objects/collections from the operation one is performing.   It's purely for readability.  This way it's unambiguous that:

/context/foo/metrics

means 'metrics' is a child object of 'foo', whereas

/contex/foo/_metrics

is a message 'please ask the metrics operation to query the 'foo' collection for these values'.


> 
>> /context/_metric?pmids=...
>> 
>> Where the query on the _metric action is across _all_ defined
>> Context names.  Other action verbs like _fetch (see below) could
>> then theoretically be applied across multiple contexts:
> 
> I've been cosidering separate contexts as belonging to independent
> concurrent users, so I'd prefer not to expose the "all contexts"
> object at all.
> 
>> /context/foo,bar,othercontextnumber3/_metric?pmids=....
> 
> This could make sense; is there any PCP precedent or need for this?
> 

probably not... there may be other cases in the protocol where a collection of <whatevers> makes sense, I had just borrowed this as a potentially example, wasn't sure if it were valid.  Just putting out there in some cases the URL protocol may like to have collections of objects as part of the objects.


> 
> I've been thinking of it as a statement that the client intends to
> poll the PCP system no less frequently than the negotiated
> poll-timeout value.  The main purpose of this is to manage the
> lifecycles of the underlying pmNewContext / pmDestroyContext
> calls, and specifically the enqueued trace-events.
> 
>> If you're meaning a timeout on the web-proxy pulling values from the
>> PMDAs then that should be a configuration value on that side, no the
>> REST or XMLRP protocol layer?
> 
> I'm not quite sure what you mean.
> 


Rereading your original post I see the creation of the context object is giving this setting as an indication of the polling frequency so this XML RPC proxy/bridge thing can make informed choices on when it's ok to automatically shut down it's internal collection to the PMDA's etc. That's probably valid.  I guess having an implicit default value configured on the RPC bridge if the client chooses to not provide one for safety?

Paul