Yes, that's correct. I had a PR to bump update times when a user switched
to a history, but it did not make it in.
re: history/current: there has been a push to make the API more stateless
and remove references to any 'current' history. Overall I still agree with
that but maybe, for such a practical case, it can be re-added for a while.
Agreed on the error, but I'd rather prioritize removing that endpoint
altogether and replace it with something better.
On Wed, May 25, 2016 at 6:14 AM, Suderman Keith <suder...@cs.vassar.edu>
> On May 24, 2016, at 11:14 PM, Carl Eberhard <carlfeberh...@gmail.com>
> most_recently_used *was* broken - thanks for finding that.
> Glad I could be of assistance! Just to clarify, the user has to actually
> *do* something with a history (i.e. add something to the history) for it to
> be considered the MRU; simply selecting switching to a history (without
> using/adding to it) is not sufficient to make it the MRU history. Correct?
> A planning issue for a session API is here:
> I will let you folks decide if a session API is appropriate, however I was
> surprised that something like /api/histories/current wasn’t an available
> endpoint. For my purposes I think this would be sufficient and this way I
> wouldn’t have to keep track of the user’s API key as well as an additional
> session cookie.
> Also, I should likely open an issue for this, but trying to access
> results in a "HTTP 500 Server Error” response. I realize (now) that this
> shouldn’t work, but it likely should result in a server error either.
> On Tue, May 24, 2016 at 4:16 PM, Carl Eberhard <carlfeberh...@gmail.com>
>> Yeah - I understand what you're trying to do now and you're right. In an
>> effort to make the API stateless I think we've introduced a gap in
>> functionality for a good, practical use case.
>> I've been wanting to replace the history/current_history* endpoints for a
>> while now with a session API (that would include a 'current' history) so
>> I'll bump that up in priority.
>> The most_recently_used may be broken - I'll check that now. Note, though,
>> that changing the current history doesn't change the update time for a
>> given history. You have to alter/change it for the time to change - then it
>> will become the 'most recently used'. It's confusing and doesn't really
>> match user expectations. I'll see what I can do about that and possibly
>> make it an alias to the above API when/if that makes it to a release. In
>> any event, again, I'll double check that it's at least doing that.
>> I'll also take a look and see if there's some other option for something
>> like this if most_recently_used won't fit the use case.
>> On Tue, May 24, 2016 at 2:16 AM, Suderman Keith <suder...@cs.vassar.edu>
>>> On May 23, 2016, at 3:34 PM, Carl Eberhard <carlfeberh...@gmail.com>
>>> There's a way to get the current history data through a non-api url:
>>> That works, but to get the current history for a user I need to set the
>>> galaxysession cookie. So it is not really a good solution unless I can find
>>> an api to determine the session cookie for the user. I’ve also noticed
>>> that /api/histories/most_recently_used is not returning the most recently
>>> used history! A bug maybe?
>>> ...but, I don't believe those are accessible through any of the
>>> bio/blend libraries.
>>> Failing the above, is there some way to get the history ID from the UI?
>>> You can click the information button ('i' with a circle around it) for
>>> any dataset in a history. The encoded history API id will be listed under:
>>> history api id.
>>> On Sat, May 21, 2016 at 7:03 PM, Suderman Keith <suder...@cs.vassar.edu>
>>>> I have been looking at the JavaDoc for Blend4J  and the REST API
>>>> , but I don’t see any way to obtain the “current” history as selected by
>>>> the user in the Galaxy UI. I see `/api/histories/most_recently_used`, but
>>>> it seems that simply selecting a history as the current history in the UI
>>>> does not make it the “most recently used” (MRU) history; I guess the user
>>>> has to actually _do_ something with before it becomes the MRU history. Am
>>>> I missing something?
>>>> Failing the above, is there some way to get the history ID from the UI?
>>>> Research Associate
>>>> Department of Computer Science
>>>> Vassar College
>>>> Poughkeepsie, NY
>>>> 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:
>>> Research Associate
>>> Department of Computer Science
>>> Vassar College
>>> Poughkeepsie, NY
> Research Associate
> Department of Computer Science
> Vassar College
> Poughkeepsie, NY
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: