[OTDev] Task redirect
Nina Jeliazkova nina at acad.bgTue Apr 27 14:17:16 CEST 2010
- Previous message: [OTDev] Task redirect
- Next message: [OTDev] Task redirect
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Martin Guetlein wrote: > On Tue, Apr 27, 2010 at 1:55 PM, Tobias Girschick < > tobias.girschick at in.tum.de> wrote: > > >> 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... >> >> > > I would very much prefer staying in the 2xx range. I am fine with Tobias > proposal. > > What about: > * task is running: 202 > * task is finished: > ** result is another task: 201 > ** result is final result: 200 > > That's does not perfectly suit the original intention behind 201, but a new > task is created so it is not totally wrong either. > Agree. Martin - if this is final decision -could you update Task wiki page? Nina > Best regards, > Martin > > > >>> 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 >> >> _______________________________________________ >> Development mailing list >> Development at opentox.org >> http://www.opentox.org/mailman/listinfo/development >> >> > > > >
- Previous message: [OTDev] Task redirect
- Next message: [OTDev] Task redirect
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Development mailing list