[SAGA-RG] Some more comments on the SAGA specs.

[Ceriel Jacobs]

Hi,

I posted the message below earlier to this list, but got no reactions,
and the bugs mentioned have not been fixed, so I think a repost is in order.
Here is the message:

> I have some more remarks/questions about the new Saga specifications,
> this time about the task package. Here they are, in random order:
> 
> Bugs:
> 
> task.wait() in the details does not specify a default value for the timeout.
> 
> PreCond on task.cancel(): sais that task is in 'Running' state, but the Notes
> say that it can also be in a final state, in which case the cancel has no
> effect.
> 
> Why does task_container.remove() return the removed task? It is already
> specified as parameter.
> 
> PostCond on task_container.run(): sais that all tasks in the container are
> in 'Running' state, but I guess the only thing you can be sure of is that the
> state is not 'New', like with task.run().
> 
> PostCond on task_container.cancel(): sais that if no timeout occurs all tasks
> in the container are in 'Canceled' state. But the tasks can be in another final
> state as well.
> 
> Debatable issues:
> 
> task_container: what is the difference between list_tasks() and get_tasks()?
> list_tasks() originally returned the cookies. Should it now return a list
> of object ids? Or should the method just be removed alltogether?
> 
> I am not sure that it is a good idea to have get_result() call rethrow().
> How do I now make a distinction between an exception coming from the get_result()
> call itself and an exception from the task? I guess that in the exception
> handler I can check the state of the task, but that does not give you a
> definite answer: if the state is "FAILED", the exception can still come
> from get_result() itself, can it not? Why not leave it to the user
> to call rethrow() if he/she wants, and as it was before?
> 
> 
> Cheers,		Ceriel
> --
>   saga-rg mailing list
>   saga-rg at ogf.org
>   http://www.ogf.org/mailman/listinfo/saga-rg

In addition, there is a small glitch in the PreCond of the task.get_result() call:
it sais that the task should not be in Failed state, which is strange, considering
that it can be in Failed state after the (implied) wait(). What I said above about
get_result() is probably a misunderstanding on my part, but it still is unclear
if any exception thrown by get_result() comes from the task itself or from the
get_result() method. For instance, if the task state is Failed, and get_result() throws
NotImplemented, is that because get_result() is not implemented or because the
method it executed is not implemented?

Cheers,		Ceriel