First, John, that "$output_dataset.creating_job.history.id" looks great! 

Ok, Dannon, I see various merits of stateless design - always providing server 
processes with the entire input array (files, params) in which no server state 
memory is referenced for a given user/agent task (aside from user state 
permissions).  

So I'm thinking John's solution is copacetic because it expresses that we're 
after a piece of information about the current process - where it is delivering 
its output - since we have other immediate processes that need to contribute to 
that work.

Thanks for your attention in revisiting this matter!

d.

Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for 
Disease Control
655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
________________________________________
From: Dannon Baker [dannon.ba...@gmail.com]
...
Subject: Re: [galaxy-dev] find UUID of current history in tool XML wrapper?

Galaxy's API goal is to be intentionally stateless, and methods that operate on 
a history accept that as a parameter and don't recognize the notion of 
'current'.  State like that is to be maintained in the client, whatever that is 
-- whether a webpage, cron job, etc.  I think this approach is probably *more* 
flexible in that we don't box ourselves into relying on the notion of a 
'current' history, though some few methods might currently rely on it.

It's worth noting that this argument has conspicuous parallels to the argument 
against allowing tools to understand the 'current' history as well.
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to