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.

On Tue, May 5, 2015 at 3:11 PM Dooley, Damion <Damion.Dooley@bccdc.ca> wrote:

P.s. I tried using BioBlend and(or) the Galaxy API to get a given user's current history but found there was no way to do so.

Seems like there is occasionally a tension between "plaform by design" (reduced instruction set, occasionally with security in mind, or dev resource limitations) and "platform for creativity" (everything exposed in case someone might find use for it).

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: Ben Bimber [bbimber@gmail.com]
...

If I'm already using non-public APIs to get the current history ID, can it be done more directly using something analogous to the above?

Thanks,
Ben
___________________________________________________________
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/