Hub resource hosting service?

[Douglas Tody]

One thing discussed way back in the original SAMP discussions was
separating the message header from the message content, which would
allow the content to be anything and defined by the messaging protocol.
This would allow real data to be passed via the messaging system,
including even binary data.  To keep things simple this was left out of
SAMP 1.0 but it was always considered a possibility for future versions.
Essentially what we have now is only the message header, with the
message type specifying what type of message it is, and parameters
providing a limited way to pass some data.

Keeping messages small and lightweight is good, but what is best really
depends upon the use case and should not be constrained by the messaging
system.  In real time applications for example (including desktop
applications such as displaying an image in real time) data can be
streamed in chunks and there is no possibility to build files which are
stored some place and then referenced by a URL or other pointer.  While
limiting messages to pointing at bulk data is a good model in many cases
it is not the only one, and ultimately it is the application which
should decide what is the best model.

I don't much like the idea of the hub being turned into a general file
store - lots of complication there with persistence issues and such.
This has nothing to do with messaging.  If such a capability is needed
it ought to be a different service, with messaging limited to only the
communication aspect.

 	- Doug


On Sun, 16 Oct 2011, Mark Taylor wrote:

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