Hi,

On Tue, 2010-04-27 at 14:29 +0300, Nina Jeliazkova wrote: 
> Martin Guetlein wrote:
> > On Tue, Apr 27, 2010 at 12:35 PM, Nina Jeliazkova <nina at acad.bg> wrote:
> >
> >   
> >> Hi Martin, All,
> >>
> >> The reason of asking about 200/202 codes is that in ToxPredict, I would
> >> prefer not to read entire content of the resultURI, in order to
> >> recognise if is a Task, or if it is a dataset, or anything else.
> >>
> >>     
> >
> > That's actually what I am doing at the moment: Parsing the results of puts
> > and posts (rdf as well as text/uri-list). If its a task, I'll wait for it.
> > I do not see how to avoid this with the current API.
> >   
> Then we need some new inventions.
> > We could agree on not returning tasks as a resultURI of other tasks. In this
> > case Tobias service would have to wait for Ambits task. 
> This is an option -actually not much different than wrapping descriptor
> calculation within a model . One drawback is of course waiting will not
> be really efficient use for the model services.
> > I do not like task
> > wrapping, though.
> >   
> Me too, harder to troubleshoot.
> 
> This is why I liked the redirect as before ... it clearly tells you the
> task is not completed, but handled by some other service, and is
> consistent with HTTP interpretation.
> > Another way of handling it could be to set the state to "Completed" but
> > leave the status to 202, in case of returning another task as resultURI. But
> > that's not a clean solution either.
> >
> > We probably have to change the API, maybe introduce 206 (Partial Content) in
> > case the task result is another task?
> >   
> Partial content has a slightly different meaning in HTTP;  so I would
> not vote for it.  Perhaps we could find other suitable error code?

I think using another status (error) code is the easiest way. However, I
am not sure, that there exists a status code that is 100% what we need
(see http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html ) for
available codes. If we stay in the 2xx range ("This class of status code
indicates that the client's request was successfully received,
understood, and accepted.") and don't go to the 3xx range ("This class
of status code indicates that further action needs to be taken by the
user agent in order to fulfill the request. The action required MAY be
carried out by the user agent without interaction with the user if and
only if the method used in the second request is GET or HEAD. A client
SHOULD detect infinite redirection loops, since such loops generate
network traffic for each redirection.") the number of possibilities is
rather small. If we reserve 200 for the whole process to be completed,
what is left is 201 (Created), 202 (Accepted), 203 (Non-Authoritative
Information), 205 (Reset Content) and 206 (Partial Content). 

Maybe the usage of 201 and 202 comes closest to what we need. But I am
not sure...

> 
> An RDF solution will be to set resultURI point to ot:Task object, rather
> than string, in case the result is a task. This is a small update, but
> will still leave the text/uri-list interpretation open.
> 
> Regards,
> Nina
> > Best regards,
> > Martin
> >
> >
> >
> >
> >   
> >> Is there any /prefered way to achieve this in the current TaskAPI ?
> >>
> >> Thanks,
> >> Nina
> >>
> >> Nina Jeliazkova wrote:
> >>     
> >>> Martin Guetlein wrote:
> >>>
> >>>       
> >>>> On Tue, Apr 27, 2010 at 11:24 AM, Tobias Girschick <
> >>>> tobias.girschick at in.tum.de> wrote:
> >>>>
> >>>>
> >>>>
> >>>>         
> >>>>> Hi All,
> >>>>>
> >>>>> On Tue, 2010-04-27 at 11:52 +0300, Nina Jeliazkova wrote:
> >>>>>
> >>>>>
> >>>>>           
> >>>>>> Hello Tobias,
> >>>>>>
> >>>>>> Tobias Girschick wrote:
> >>>>>>
> >>>>>>
> >>>>>>             
> >>>>>>> Hello All,
> >>>>>>>
> >>>>>>> we removed the redirect from the TUM task services as suggested by
> >>>>>>> Martin. All Tasks now return the resulting URI and status code 200 on
> >>>>>>> finishing. No automatic redirects anymore.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>               
> >>>>>> Just to clarify - if a model completes execution and posts the result
> >>>>>> dataset to the dataset service, what will be returned - 200 or 202 ?
> >>>>>>
> >>>>>>
> >>>>>>             
> >>>>> Now I return 200. How are other groups handling this, e.g. Pantelis?
> >>>>> Martin?
> >>>>>
> >>>>>
> >>>>>
> >>>>>           
> >>>> Hello Tobias, Nina,
> >>>>
> >>>> I would expect 202 as long as the task is running,
> >>>>
> >>>>         
> >>>       
> >>>> 202 as soon as the task
> >>>> is finished.
> >>>>
> >>>>         
> >>> I guess you mean 200.
> >>>
> >>>       
> >>>>  The resultURI of the task maybe another task tough.
> >>>>
> >>>> So in Tobias Case:
> >>>> * model building returns tum-task with 202 while the model is running
> >>>> * model finishes: the results are posted to ambits dataset service, the
> >>>> model service receives an ambit task
> >>>> * tum-task is set to 200, resultURI of tum-task is set to ambit-task
> >>>>
> >>>>
> >>>>         
> >>> Then how do you distinguish between resultURI pointing to another task
> >>> and final result (a dataset, anythig else),  if both have 200 code ?
> >>> This can be done if reading RDF representation, but not text/uri-list.
> >>>
> >>> Does it mean we should drop uri-list ?
> >>>
> >>> Best regards,
> >>> Nina
> >>>
> >>>       
> >>>> Best regards,
> >>>> Martin
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>         
> >>>>> Nina told me that returning 200 will cause Problems with ToxPredict (at
> >>>>> the moment). What exactly is expected by the validation services?
> >>>>>
> >>>>> We definitely need a uniform solution here. What do other developers
> >>>>> think? I have no problem returning 202 on completion (calculation
> >>>>> completion) if the complete job is still not done (e.g. AMBIT upload
> >>>>> initiated by my service).
> >>>>>
> >>>>> regards,
> >>>>> Tobias
> >>>>>
> >>>>>
> >>>>>
> >>>>>           
> >>>>>> Best regards,
> >>>>>> Nina
> >>>>>>
> >>>>>>
> >>>>>>             
> >>>>>>> @Martin: Could you check if everything works fine now with the
> >>>>>>> validation services?
> >>>>>>>
> >>>>>>> regards,
> >>>>>>> Tobias + Fabian
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>               
> >>>>> --
> >>>>> Dipl.-Bioinf. Tobias Girschick
> >>>>>
> >>>>> Technische Universität München
> >>>>> Institut für Informatik
> >>>>> Lehrstuhl I12 - Bioinformatik
> >>>>> Bolzmannstr. 3
> >>>>> 85748 Garching b. München, Germany
> >>>>>
> >>>>> Room: MI 01.09.042
> >>>>> Phone: +49 (89) 289-18002
> >>>>> Email: tobias.girschick at in.tum.de
> >>>>> Web: http://wwwkramer.in.tum.de/girschick
> >>>>>
> >>>>> _______________________________________________
> >>>>> Development mailing list
> >>>>> Development at opentox.org
> >>>>> http://www.opentox.org/mailman/listinfo/development
> >>>>>
> >>>>>
> >>>>>
> >>>>>           
> >>>>
> >>>>         
> >>> _______________________________________________
> >>> Development mailing list
> >>> Development at opentox.org
> >>> http://www.opentox.org/mailman/listinfo/development
> >>>
> >>>       
> >> _______________________________________________
> >> Development mailing list
> >> Development at opentox.org
> >> http://www.opentox.org/mailman/listinfo/development
> >>
> >>     
> >
> >
> >
> >   
> 
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development


-- 
Dipl.-Bioinf. Tobias Girschick

Technische Universität München
Institut für Informatik
Lehrstuhl I12 - Bioinformatik
Bolzmannstr. 3
85748 Garching b. München, Germany

Room: MI 01.09.042
Phone: +49 (89) 289-18002
Email: tobias.girschick at in.tum.de
Web: http://wwwkramer.in.tum.de/girschick