http://bugzilla.moblin.org/show_bug.cgi?id=3604





--- Comment #13 from pohly <[email protected]>  2009-09-03 23:50:54 ---
(In reply to comment #11)
> (In reply to comment #10)
> > * How does the code handle non-HTTP server passwords? I don't see
> >   any kind of check for that in the code. getServerUsers() seems
> >   to assume that it will invoked only for the "password" property
> >   in the main config.ini. That's not the case. Most likely you
> >   have to add more parameters to askPassword and savePassword
> >   to handle the other cases, because the "description" string
> >   doesn't help.
> I've added 'ConfigNode' into the parameter list. For non-HTTP server 
> passwords,
> such as source related password 'evolutionpassword', source config will also 
> be
> transferred.If this is not enough, then I think it could add a string list in
> the parameter list. I learned from your previous mail that you prefer to let
> ConfigUserInterface to access EvolutionSyncConfig and SyncSourceConfig?

I haven't really thought much about this. If it can be done without breaking
the abstraction layers, then it would be a cleaner way to access specific
config properties, like "sync URL". On the other hand, the caller of
askPassword/savePassword might not know what the currently active
EvolutionSyncConfig and SyncSourceConfig is.

> > * Why is the branch with 're-write the password value with a string "-"'
> >   commented out? This is necessary.
> Because I've moved this to config system 'PasswordConfigProperty'. If password
> is saved by UI, then config system saves its value by '-' because it knows
> saved password's name and more detailed information instead of UI.

I see. The dead code in CmdlineSyncClient::savePassword() confused me. Better
remove it.

The "return false" after "throwError" will never be reached. If it was, what is
the caller of savePassword() to do if it gets a "false" return code? Currently
the caller silently doesn't do anything and the password isn't saved. I doubt
that this is useful. I think savePassword() doesn't need a bool return code and
should either do the job or throw an error.

> > * I don't understand why overriding the flush() method is necessary.
> Yes, I also hesitate about it for there are 2 choices. If no flush, then user
> needs to call 'savepassword' explicitly. If invoking this function in the 
> flush
> method, then password saving will be done automatically. In a word, I have no
> inclination.

I still don't understand; I'll have a look how this works at runtime in the
next revision of the patch.

-- 
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
_______________________________________________
Syncevolution-issues mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution-issues

Reply via email to