[ome-devel] Shoola login sequence issues

[Harry Hochheiser]

I've  got some questions/concerns about the shoola login sequence that 
I'd like to discuss..

As initially implemented, Shoola was apparently designed to reflect the 
stateless nature of the server.  Although shoola presents the user with 
an initial login screen, the model did not require a 
constantly-available legitimate connection. Instead, if a user made a 
request to the server _without_ being logged in, properly designed 
agents would request a user name and password, login to the server, and 
process the request. Or, sort of  - in actuality, they might choose to 
return to some reasonable state, instead of continuing with the exact 
request as processed.

As this model was not documented, I wrote several shoola agents that 
did not implement this behavior.

A few months back, I took a look at the login sequence. Unaware of this 
  model of managing sessions, I revised the Shoola login screen to 
require a valid user name and password. Essentially, given an invalid 
user name/password, the login screen would throw up a notifier dialog 
window and then return itself to wait for another login attempt.

This code was recently removed from CVS, in favor of the original code.

In the generic sense, I think it would be appropriate/nice/helpful to 
try to alert folks before we make changes to CVS that essentially 
"undo" work that others have done. Presumably a change was made for a 
reason.  I had good reasons for making that change  - one of which was 
to fix a bug: http://bugs.openmicroscopy.org.uk/show_bug.cgi?id=370. 
Now, it's entirely possible that the other changes that were made 
elsewhere allowed the code to be rolled back without re-introducing the 
bug,  but that's hard to tell from the CVS comments or bugzilla.  Can 
we try to discuss such changes in the future?

In the particular sense, I think this handling of the login behavior is 
not ideal.

- From a practical viewpoint, my agents are not built to correctly 
respond to requests when an OMEDS connection is not available. As I 
mentioned above, this requirement was not documented. Furthermore, it 
is not supported transparently by the OMEDS code: all agents must 
implement it individually.  It might be possible to modify OMEDSGateway 
to do this login work - I'm not sure. If this can't easily be done, it 
would take me a non-trivial amount of effort to revise my agents to fit 
this model, and that's not really work that I want to do right now.

- From a UI viewpoint, this model has the potential to confuse the hell 
out of users.  As it stands now, someone can provide an incorrect  user 
name/password at the start of Shoola, press "login", try to start an 
agent, and then be presented with a new login screen".  I think this is 
going to be very confusing for many users.

So, I'd like to suggest that we restore the code that requires a 
legitimate login before doing any work in Shoola. In this model, the 
code is built to recover nicely in the absence of a connection will 
still work fine,  and other agents (ie., my code) will continue to 
function well.

-harry