http://bugzilla.moblin.org/show_bug.cgi?id=3604
--- Comment #13 from pohly <patrick.ohly(a)intel.com> 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.