TAP 1.0: Substantive comments.

[Tom McGlynn]

Patrick Dowler wrote:
...
> A detail question: in interacting with an async (UWS-based) service, one can 
> set params on the server side in a series of POSTs, starting with the POST 
> that creates the job. That is, one can create the job, then POST various 
> params u pto the point where one POSTs PHASE=RUN to start the job. Once you 
> start a job you can no longer modify it. So, if one is to use 
> 
> UPLOAD=mytable_name,inline:mytable_content
> 
> would the inline content have to be delivered in the same POST as the UPLOAD 
> param that connects the TAP table name with the content? I would assume this 
> is required but just checking that this is what we mean. 
> 

I hate cluttering up the standard with special cases. [Can you tell!] 
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.  Since the whole capability is 
optional perhaps that's not a problem.

There is no cost to this so long as the UPLOAD request precedes any file 
upload parameters if the server is mildly intelligent.  If the UPLOAD 
comes first then the file upload parameters are immediately 
recognizable.  Indeed I could imagine a mode where a user sends up a set 
of uploaded files one by one in separate requests and then does the 
query.  A very large upload set could be broken into more handleable chunks.

However I've done very little with this kind of async service, so I may 
be misunderstanding how it works.

	Tom