sebb <email@example.com> wrote on 11/25/2005 12:22:33 PM:
> > Consider the case the values in Subclipse are invalid. What happens
> > pass these to the client adapter. It tries to use them and it fails.
> > the adapter then prompts you for new values, which work. The problem
> > that Subclipse does not know that you were prompted, so it has no way
> > update the stored values. Consequently, the next time you try to do
> > operation which needs credentials you go through this process all over
> > again.
> If they are then changed in the dialogue box, it will then work from
No. Only if the user somehow knows that they have to go back into the
Subclipse repositories view and make the same change there.
> > It is just better if this information is not stored at all in
> > Comparisons with CVS are unfair as it has complete end to end control
> > the solution where as Subclipse has to interact with a library that
> > from some place else.
> That may be so (at present), but as far as the user is concerned, all
> they see is the Subclipse interface.
It doesn't change the fact that our hands are tied in making it any
> > Finally, I will just point out that when the command line adapter is
> > then you can still specify the username and password as that adapter
> > not have any prompting support and therefore needs the information to
> > passed in.
> OK, so why not leave it up to the user whether or not they want to
> store the information in Subclipse - for all connectors?
Because that is the way it has always worked and there have been a lot of
complaints about it and it leads to general confusion. I do not
understand the objection to allowing the adapter to manage the
information. Unlike Subclipse, they encrypt the information and they also
have the ability to do things like prompt and recache when your password
The other issue is that for the file:// and svn+ssh:// URL's the username
and password do not apply. So ideally we would have to parse the URL as
you type it and dynamically show/hide those fields, which seems a bit odd
from a UI point of view.
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Sat Nov 26 04:45:48 2005