Re: [pcp] sketch of possible web pmapi

["Frank Ch. Eigler" <fche@redhat.com>]

Hi, Paul -


> This is great.  This looks RESTful, but not sure if that was the
> intent.  Would be worth following the REST pattern fully.

I read about REST, but only with web-app newbie eyes.

> Also, I think JSON is a better text output format and now much
> easily parseable by both humans AND code too.  [...]

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.

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


> >       /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.


> >  - 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?


> /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?


> >       /context/CONTEXT/value?pmids=ID1,ID2,ID3
> >       /context/CONTEXT/value?pmids=ID1,ID2,ID3&time=TIME
> 
> What about:
> 
> /context/{contextname}/_fetch?....

Sure, no strong opinion.


> [...]
> I think the poll-timeout should be a client value, not part of the
> protocol..?  Did you mean that?

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.


> [...] Getting ahead of myself here, a 'pcp-head' JavaScript UI
> client like Ben's ElasticSearch one could include graphs etc
> too... Perhaps a nice cross platform pmchart replacement... *ducks*.

This is what we have in mind as a potential eventual result.

- FChE