TAP 1.0: Substantive comments.

[Doug Tody]

On Mon, 31 Aug 2009, Patrick Dowler wrote:

> On Monday 31 August 2009 13:04:50 you wrote:
>> If this is permitted for other parameters then I'd want to try to treat
>> this the same for file uploads as everything else.  As I see it the cost
>> is that we need to preserve parameters that might be file upload
>> parameters until we get the RUN request.  But I think the typical
>> implementation is going to preserve all of the parameters in some
>> fashion anyway until the RUN request is made so the only real difference
>> is that these will be longer than most.
>
> On Monday 31 August 2009 13:05:39 you wrote:
>> My conclusion is we don't need to say anything special about UPLOAD
>> where UWS is concerned.
>
> OK, that makes sense. It is true that in our UWS framework the generic code
> collects everythijng together and service-specific (eg TAP) code only sees it
> when the job runs.
>
> Do we have any feeling/sense on a scheme for the URI? inline?

This is worth careful thought as the mechanism is not specific to
TAP and we will probably want to use it in other service interfaces,
e.g. other DAL2 services like SIAV2.

It would seem that what we have here is the client inputting arbitrary
file content at runtime in the same way that we input parameters.
It is logically part of the runtime service interface or API like an
input parameter.  So the data is "inline", it is like a parameter,
it is part of a runtime session and gone afterwards.  Words which
express this include "inline", "param", "session", and the like.

One possibility would be to more formally associate inline file
uploads with the parameter mechanism.  Hence we might have

     UPLOAD=<mytable_name>,param:<param_name>

where the intent is that a file uploaded in a POST with a
multipart/form-data attachment would be considered a type of
client-supplied input parameter (if Tom is right this may be how
typical HTTP/CGI packages work anyway).  Hence in the UWS use
case as the code collects input parameters it would store the
multipart/form-data file content in a dynamically created "data"
type input parameter.  When later we resolve the UPLOADS, file data
would be taken directly either from the specirfied HTTP URL or from
the named data parameter without any complex semantics.

In the case of HTTP, POST and GET would be very similar as in Tom's
example (a POST with multipart/form-data would be preferred and has
the advantage that one could explicitly specify the content type and
encoding of the file data).  If we were using methods other than HTTP
to invoke the service, for example by passing in a parameter set,
the file data could be passed directly as a parameter.

Name collisions would be possible as the uploaded multipart/form-data
"NAME" would share the same namespace as the input parameters.  However
NAME is assigned by the client and can now be anything, since it is
no longer the actual table name in TAP.  Since the client provides all
input parameters it should not be difficult to avoid name collisions.
We can safely leave it up to the client code to deal with this.

Regarding whether "inline" or "param" is a unique URI prefix, here is
what Wikipedia gives for existing URI prefixes:

URI schemes
   Official
     aaa · aaas · acap · cap · cid · crid · data · dav · dict · dns ·
     fax · file · ftp · go · gopher · h323 · http · https · im · imap
     · Info · ldap · mailto · mid · news · nfs · nntp · pop · pres ·
     rtsp · sip · sips · snmp · tag · tel · telnet · urn · wais · xmpp

   Unofficial
     about · afp · aim · apt · bolo · bzr · callto · cel · cvs ·
     daap · ed2k · feed · fish · gg · git · gizmoproject · iax2 ·
     irc · ircs · itms · lastfm · ldaps · magnet · mms · msnim ·
     psyc · rsync · secondlife · skype · ssh · svn · sftp · smb ·
     sms · soldat · steam · unreal · ut2004 · view-source · vzochat ·
     webcal · wyciwyg · xfire · ymsgr

So we are ok either way - pragmatically it is not likely to be an
issue anyway as all these URI schemes do not come together in any
actual real world application, certainly not in our applications.

 	- Doug