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
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
Thanks for your attention in revisiting this matter!
Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for
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:
To search Galaxy mailing lists use the unified search at: