TAP 1.0: Substantive comments.

[Doug Tody]

On Mon, 31 Aug 2009, Tom McGlynn wrote:

> - The current design strongly couples the semantics and the transport 
> protocol.   I.e., all of the data that is transported using a particular 
> syntax in HTTP POST's is to be treated as a file upload.  This has two major 
> negative consequences.  It makes TAP more HTTP dependent since rather than 
> using the abstraction of keyword/value pairs which could easily be 
> implemented on some other protocol we need to look at exactly how we encoded 
> data within the transport protocol to understand what certain parameters are. 
> If we want to layer TAP on some new XXXTP we have to explicitly think about 
> how file uploads work.  It would come for free if we just use the same 
> keyword/value abstraction we use everywhere else.
>
> Even worse, we've now precluded TAP, and all protocols layered on top of it 
> (ADQL, PQL, ...), from using in-line file uploads for any purpose other than 
> table uploads.  What happens when we want to layer in a security protocol 
> that needs to include a certificate as a file upload?  Or a user 
> customization file or a file that ADQL6 uses to allow users to dynamically 
> define a metadata structure or ....  We need to leave space for this kind of 
> growth.

If I understand the point correctly, the issue here is that in the
case of in-line table uploads we are unnecessarily "hiding" the upload
within the HTTP protocol.

If instead we were to use a parameter to associate the upload with
a table what might this look like and what would we gain?  We might
have something like the following (not yet a carefully thought out
proposal):

     UPLOAD=myTable,inline:<multipart-name>

which would associate the named table myTable with an inline uploaded
file.

For reference here is the existing URI upload usage:

     UPLOAD=myTable,http://example/com/mytable.xml

Use of the UPLOAD parameter for inline uploads would allow NAME to
be anything and would allow other types of file uploads (which was
always a goal, e.g., security certificates, encoded STC masks, etc.).
It might also be possible to better separate the logical interface
from the specific HTTP usage so long as we have a way to associate the
uploaded file - probably still using the NAME value for a multipart
upload, although with this chance the NAME could be anything.  It will
still be necessary to specify the HTTP usage in the document however.

This looks like it could work, and would probably be an improvement
to the interface.

> The class explicitly tries to hide the underlying HTTP encoding --
> just as it hides the difference between parameters encoded in GET's
> versus POST's.

The DALServer framework does this as well.  All the real service
code is in protocol-independent classes, with the HTTP-specific code
handled in a wrapper class.

I was not aware of any issue with name collisions for a form NAME
and a HTTP parameter, but probably you are right about that being a
potential problem.

 	- Doug