Hub resource hosting service?

[Mark Taylor]

Hi all.

Here is an issue, and a possible solution, which was raised by some
Web Profile implementation work that Tom is doing.  We will discuss
it in the Apps SAMP session on Thursday, but I wanted to air it here
first to give people time to think about it, and also to solicit
comments from people who are not in Pune. 

Tom said:

On Fri, 14 Oct 2011, Tom McGlynn wrote:

> A final largely unrelated issue...  SAMP's reliance on passing VOTables only
> via URLs makes it difficult to adapt to JavaScript clients.  They have to
> create relay URLs, stage results, or duplicate functionality on the server
> side.  E.g., if we were to want to send a VOTable that had been filtered
> using VOView, there is no easy way to do this that I know of.  I'm sure this
> was considered early on, but it's possible to do quite extensive processing
> in the web browser now and we may wish to consider supporting that,
> especially with WebSAMP.  E.g., we might allow either 'url' or 'content'
> tags in the message (where the later would be the actual VOTable content) or
> defining equivalent mtypes for messages with table content.

This hadn't occurred to me before.  I had assumed that if web apps
needed URLs to pass around they would come from the origin HTTP server.
While an app could pass locally generated/manipulated data back to its 
origin server and send the resulting URL around in SAMP messages it's
clearly not an efficient solution, since the data starts and ends on
the client so doesn't want to have to go via a remote server.

Tom's suggestion of adding content parameters as an alternative to url
parameters in MTypes is possible, but a bit unpalatable for a couple
of reasons.  First it falls foul of the SHOULD (though not MUST) in 
SAMP section 3.3 that says:

   "General purpose MTypes SHOULD therefore be specified so that bulk
    data is not sent within the message. In general it is preferred to
    define a message parameter as the URL or filename of a potentially
    large file rather than as the inline text of the file itself."

largely to prevent clients having to deal with very large chunks of XML,
which is especially a problem if they DOMise them as a matter of routine.
Second it means that a lot of new messages (or at least new versions
of messages, using content rather than url parameters to specify
content) would be flying around and old clients wouldn't be able to
handle them, until they were upgraded accordingly.

Another way to look at the problem is that Web Profile SAMP clients lack an
efficient resource hosting mechanism (since, unlike Standard Profile 
clients, they are unable to write temporary files or host HTTP servers).
This could be addressed by allowing the hub to provide such a mechanism.
The most straightforward thing would be for the hub to provide a URL 
to which documents could be POSTed in return for a (201 Created -
see RFC2616 sec 9.5) Location URL.  Web clients which want
to pass data to another client could therefore POST the docuement to
the hub, get a reference URL in return, and pass that reference URL
in messages.  The hub arranges to redeliver the content to anyone
who asks for it via that reference URL later.
This also isn't perfect, since it means the hub has to manage some
client resources rather than clients, but to me it seems cleaner.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/