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.baker@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.