[ome-devel] Shoola login sequence issues

[Andrea Falconi]

Quickies:

> This code was recently removed from CVS, in favor of the original code.
That was an overight on our party.  We want to keep the *same* behavior as 
the new code, but need to modify the impl b/c that code has threading 
issues -- which show up sometimes in the UI thread; for example after 
entering the wrong usr/pass in the splash screen the notification dialog 
might pop up more than one time in a row.  That's why some of that code 
disappeared; we're in the process of replacing it.  But behavior will be the 
same.

>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.
Sure, but we're not undoing anything, just replacing w/ a better 
implementation.

Sorry about the confusion.

andrea

----- Original Message ----- 
From: "Harry Hochheiser" <hsh at nih.gov>
To: "OME Development" <ome-devel at lists.openmicroscopy.org.uk>
Sent: Thursday, May 12, 2005 7:52 PM
Subject: [ome-devel] Shoola login sequence issues


>
> 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
>
>
>
>
>
>
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>