On Thu, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote: > As usual this is turning out to be a bigger job than expected, and I'm > less confident now that I can get this all done by 2.91.90 but I'm still > gonna try. The alternative, since I -really- don't want these XML blobs > creeping into GSettings even temporarily, is to depend on GConf for 3.0 > and then land this stuff (along with Rodrigo's GSettings branch) early > in 3.1. Were it not for the pressure to get everything converted in > time for GNOME 3.0, I would already be retargeting this for 3.1.
Hi, sounds reasonable, this seems to be quite intrusive change, not only for evo itself, but for everyone using it, so landing in time of .90 might be rather bad. Apart of that we have enough such changes in sources already, counting also gtk3, so I'm 111% for postponing to early 3.1. > libedataserverui > ---------------- > > - All e-passwords functions will simply take an ESource instead of > "component" and "key" strings. Keyring entries will contain the > UID of the corresponding ESource instead of URI components (we'll > convert existing keyring entries as part of the migration phase). It would be good to allow also username changing in EPasswords. It's very unusual to allow only password entering when most applications are allowing to change both username and password (I'm not aware of any other with "enter password only" functionality at the moment). It seems to be related, a bit, thus I'm bringing it here. Also note one thing which might require a bit rewriting. If I recall correctly you would use the ESource's UID for password storing. The thing is that evolution allows setting "auth-method", which is used as 'component'. The advantage of this is that the ESource for calendar can share password from mailer (while not knowing the parent source/account at all), because they are using same 'component' and 'key'. So with your change in the passwords there should be a knowledge to which account is this ESource tight (which is not always clear right now?), and this "parent" account should be used instead of the actual ESource, right? I do not want to complicate things much here, though with the "change also user name" proposal above it might mean that one wouldn't use different name for calendar and a different name for mailer with this? I think we are not using any such approach here anyway, so I'm only brainstorming here. Bye, Milan P.S.: If you'll be changing API, please change also EIterator API, to not return 'const' pointers from e_iterator_get. We use to forget to change this release by release :) _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers