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.

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
>



-- 
Dipl-Inf. Martin Gütlein
Phone:
+49 (0)761 203 8442 (office)
+49 (0)177 623 9499 (mobile)
Email:
guetlein at informatik.uni-freiburg.de