Re: [pcp] sketch of possible web pmapi

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

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 <A>'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