Re: [Evolution-hackers] Rethinking account management
On Sun, 2012-04-29 at 19:50 -0400, Matthew Barnes wrote: > It's been awhile since I've posted a progress update on this branch, but > I just wanted to mention that as of this weekend I think I finally have > Evolution pretty much wrapped up now and am moving on to the groupware > modules starting with Evolution-EWS, since I'm also on the hook for > integrating EWS with the new Exchange support in GNOME Online Accounts. Yay, good work. Thanks. When you're doing the groupware back ends, please don't forget the evolution-activesync is in GNOME git too, now! :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
It's been awhile since I've posted a progress update on this branch, but I just wanted to mention that as of this weekend I think I finally have Evolution pretty much wrapped up now and am moving on to the groupware modules starting with Evolution-EWS, since I'm also on the hook for integrating EWS with the new Exchange support in GNOME Online Accounts. I'm sure I'll have more tweaks and bug fixes for Evolution and E-D-S, especially since I haven't really handled groupware accounts under the new ESource API yet, although I've tried to anticipate what we'll need. I already have patches written for the GNOME Shell calendar and GNOME Panel calendar applets, and have alerted the Telepathy/Folks developers about the upcoming breaks [1]. I tried to patch the E-D-S Folks backend myself but my feeble Vala skills just aren't up to the task. So I think I'm on track to merge this branch during this cycle, though I dare not predict a merge date just yet. I think once I finish off EWS I'll have a much more accurate sense of the remaining work ahead of me. I rebased both Evo and EDS branches on 3.5.1 today, so feel free to try them out if you're curious. Just be cautious of the account migration: it's a one-way trip. Maybe test it on a different user account for now. Matthew Barnes [1] http://lists.freedesktop.org/archives/telepathy/2012-April/006072.html ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Thu, Mar 1, 2012 at 8:13 PM, Matthew Barnes wrote: > I added a page to our wiki about the upcoming file format for account > data. It focuses more on the nuts and bolts of the file format itself > rather than the APIs used to access the data. In particular, I wanted > to get the mail account format written down somewhere since it's a bit > more complex than the rest. > This is good to have. Lemme go through them to see if I see any issues there -Srini. > http://live.gnome.org/Evolution/ESourceFileFormat > > Matthew Barnes > > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
I added a page to our wiki about the upcoming file format for account data. It focuses more on the nuts and bolts of the file format itself rather than the APIs used to access the data. In particular, I wanted to get the mail account format written down somewhere since it's a bit more complex than the rest. http://live.gnome.org/Evolution/ESourceFileFormat Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Wed, 2011-09-14 at 11:27 +0200, Christian Hilberg wrote: > > Doing his will finally make it possible to configure address books and > > calendars for E-D-S independently of Evolution. With that in place, we > > can start adding some nice desktop integration. > > Has there already been a manifestation of that Evo-independent backend > configuration? I haven't actually split them off from Evolution yet, but the address book and calendar configuration modules are here under the "book-config" and "cal-config" directories: http://git.gnome.org/browse/evolution/tree/modules?h=account-mgmt They replace the equivalent EPlugins currently on the master branch. However they require base classes which are not presently in master, such as ESourceConfig and ESourceConfigBackend. Making them Evo-independent is just a matter of moving those directories and required base classes to Evolution-Data-Server. If there's time I'll try to do that for 3.4, or I may let them remain in Evolution for 3.4 and move them to E-D-S for 3.6. We'll see how things play out. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
Hi, Am Dienstag 18 Januar 2011, um 20:32:44 schrieb Matthew Barnes: > [...] > Now I'll let you in on my master plan: > > Either in the 3.2 or 3.4 time frame, after the branch is merged and has > some time to settle in and stabilize, I want to move these configuration > dialogs to Evolution-Data-Server and also write some simple command-line > tools to run the dialogs. > > Doing his will finally make it possible to configure address books and > calendars for E-D-S independently of Evolution. With that in place, we > can start adding some nice desktop integration. Has there already been a manifestation of that Evo-independent backend configuration? Kind regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
I just pushed a new snapshot of my "account-mgmt" branch for Evolution and Evolution-Data-Server. http://git.gnome.org/browse/evolution/log/?h=account-mgmt http://git.gnome.org/browse/evolution-data-server/log/?h=account-mgmt This is mostly for backup -- I haven't yet reached any particularly significant milestone, and the mailer is currently broken. But it's been a long time since my last public snapshot and I'm about to start messing around with the new D-Bus service I talked about in [1], which will require rewriting some of my own rewrites. I need a fresh backup in case things go pear-shaped. Up-to-date documentation for the new ESource API can still be found at: http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/ [1] http://mail.gnome.org/archives/evolution-hackers/2011-August/msg00025.html ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
There's a really interesting thread over on desktop-devel-list. David Zeuthen is taking on the task of desktop-wide online account management for GNOME 3.2, with E-D-S integration among other things. What he's describing sounds like the missing piece in my account management redesign for dealing with online services and groupware accounts. I've already said as much on the list. Everyone should read this: http://mail.gnome.org/archives/desktop-devel-list/2011-April/msg00107.html ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Wed, 2011-03-30 at 07:49 +0200, Milan Crha wrote: > should it delete them too? I've a feeling there is no need for it, > especially when you want to have them as three separate independent > objects. But that's just a feeling. As long as Evolution treats account/identity/transport triplets as a single unit, I think they should be created and destroyed together. If and when Evolution allows you to define identities and transports independently of accounts, then we should reconsider like you said. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Tue, 2011-03-29 at 09:26 -0400, Matthew Barnes wrote: > The hierarchy just ensures that deleting the mail account from the > ESource registry will also take out the default identity and transport > for that account. Hi, should it delete them too? I've a feeling there is no need for it, especially when you want to have them as three separate independent objects. But that's just a feeling. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
In last week's IRC meeting I promised more details about the file format I'm designing for mail accounts. I like the way Thunderbird splits accounts, identities and transports into orthogonal concepts. Each account has a default identity and transport, but then you can go back and define additional identities and transports. We've had numerous requests for this capability over the years, but we can't really do it with the current architecture. Right now you have to define a complete account for every different identity you want. So I'm trying to at least build Thunderbird's flexibility into the file format, even if Evolution can't yet take advantage of it. First, to clarify these terms: Generally, a mail account describes a mailbox on some host that holds your email. A mail account object in Evolution will hold authentication details for accessing that mailbox, and further settings for interacting with it such as how often to check for new messages, whether to synchronize the mailbox contents locally for offline viewing, etc. Eventually I'd like to move new mail notification settings here as well. A mail identity describes what information recipients will see when they read your messages. So things like your name, email address, reply-to address, signature, etc. A mail identity object in Evolution will also describe things that Evolution should do automatically when composing and sending messages. This includes signing and/or encrypting outgoing messages, automatically adding Cc: or Bcc: recipients, what folder to put sent messages in, etc. Eventually I'd like to move composer preferences here as well: things like whether to compose in HTML mode, preferred reply and forward styles, where to insert the signature, etc. And last but not least, a mail transport is generally going to describe an SMTP server and hold authentication details for it. So. My plan is for a complete mail account (as Evolution defines mail accounts currently) to consist of three separate ESource objects, and hence three separate key files, arranged hierarchically like so: +--+ | Mail Account | | uid: aaa | +--+ /\ +---+ ++ | Mail Identity | | Mail Transport | | uid: bbb| |uid: ccc| +---+ ++ The hierarchy just ensures that deleting the mail account from the ESource registry will also take out the default identity and transport for that account. Here's a skeletal example of all three key files, minus all the extra options. Remember that each key file group, other than [Data Source], is handled by a unique subclass of ESourceExtension. So all I'm really doing here is defining new ESourceExtension subclasses for mail stuff. I'm also reusing existing extensions such as [Authentication] which are also used in address books and calendars. Mail Account (uid: aaa) --- [Data Source] DisplayName=My Account BackendName=imapx Parent= [Authentication] Host=my.mail.server.com Method=ssl Port=993 RememberPassword=true User=mbarnes [Mail Account] Enabled=true Identity=bbb# Refers to the default Mail Identity (uid: bbb) [IMAP+ Backend] ...backend-specific options go here... Mail Identity (uid: bbb) [Data Source] DisplayName=Matthew Barnes BackendName= Parent=aaa [Mail Identity] Name=Matthew Barnes Address=mbar...@redhat.com ReplyTo= Organization= Signature= Transport=ccc# Refers to the default Mail Transport (uid: ccc) Mail Transport (uid: ccc) - [Data Source] DisplayName=smtp.mail.server.com BackendName=smtp Parent=aaa # The 'placeholder' key is just that. Every group needs at least one # key in order to appear in the key file, but there's nothing really to # put here at the moment. A little awkward, but I can live with it. [Mail Transport] Placeholder=For future transport options [Authentication] Host=smtp.mail.server.com Method=none Port=25 RememberPassword=false User= With this much figured out, I have removed EAccount and EAccountList from libedataserver on my "account-mgmt" branch and am now trudging through Evolution trying to put it back together using the time-tested "figure the rest out as I go" approach. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Tue, 2011-03-01 at 23:02 -0500, Matthew Barnes wrote: > My next steps are to write the migration code for all the XML blobs in > our "sources" GConf keys, and then it's on to mail accounts. I rebased the "account-mgmt" branches [1] again to snapshot my progress. Address book and calendar migration is done now for both GConf keys and keyring entries, and I've spent the past week polishing, documenting and even writing some unit tests (!) for the new ESource class and other libedataserver APIs. I also posted browsable documentation for the new APIs here: http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/ Next, I'm finally moving on to converting mail accounts into ESources. I have some vague ideas of how this will work, but I don't want to say too much more until I have a better grasp of just what the heck I'm getting myself into. Wish me luck. I'll report back again once I'm in the thick of it. [1] http://git.gnome.org/browse/evolution-data-server/log/?h=account-mgmt http://git.gnome.org/browse/evolution/log/?h=account-mgmt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Tue, 2011-01-18 at 14:32 -0500, Matthew Barnes wrote: > I think I'm done now with the standalone address book backends and am > moving on to calendars, so it seemed like a good stopping point for a > status update. > > I pushed snapshot branches named "account-mgmt" to git.gnome.org. Try > them if you're curious, but they're mainly for backup so I don't lose > three months of work if my hard drive dies or I do something stupid. > > http://git.gnome.org/browse/evolution-data-server/log/?h=account-mgmt > > http://git.gnome.org/browse/evolution/log/?h=account-mgmt Standalone calendar backends are now done. I removed the previous "account-mgmt" branches from git.gnome.org and pushed new ones. The links above now point to the new branches. My next steps are to write the migration code for all the XML blobs in our "sources" GConf keys, and then it's on to mail accounts. Only thing worrying me at this point is the mail account editor. I'm really hoping I can avoid a massive rewrite of that beast. That would easily add a month to this project. Its time will come, but not now. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Thu, 2011-01-27 at 08:15 +0100, Patrick Ohly wrote: > On Mi, 2011-01-26 at 11:34 -0500, Matthew Barnes wrote: > > Can you elaborate on the creation use case? Sounds like you're creating > > local data sources on the fly? > > Yes. The primary use case is in automated testing. Instead of having to > create the database in advance via the GUI, the test driver does it > automatically. For automated testing you could either predefine a set of key files -- each of which pointing to a different .ics file -- or generate the key files on the fly. Haven't nailed down the exact format of the backend group yet but it would look something like: [Data Source] Parent=local DisplayName=Test 1 [Calendar] Color=#whatever Enabled=true [File Backend] Location=file://path/to/test.ics The test fixture would then load the directory containing these key files into the registry: ESourceRegistry *registry; GList *sources, *iter; registry = e_source_registry_get_default (); e_source_registry_load_directory (registry, "/path/to/key-files"); /* Give me all the test ESources. */ sources = e_sources_registry_list_sources (registry, NULL); /* Run each test. */ for (iter = sources; iter != NULL; iter = g_list_next (iter)) run_test (E_SOURCE (iter->data)); g_list_free (sources); ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Mi, 2011-01-26 at 11:34 -0500, Matthew Barnes wrote: > Can you elaborate on the creation use case? Sounds like you're creating > local data sources on the fly? Yes. The primary use case is in automated testing. Instead of having to create the database in advance via the GUI, the test driver does it automatically. I've also heard of users who read and write .ics files in arbitrary locations by using the calendar backend with a file:// uri. These are KDE users who then read and write these files via KOrganizer - a bit crude, but usable. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Wed, 2011-01-26 at 16:23 +0100, Patrick Ohly wrote: > SyncEvolution uses all of these calls. I don't mind rewriting the code, > but let's make sure that there is a proper replacement. > > What I need to do is: > - list all address books and calendars > - open any of the listed databases > - create new ones at a location chose by the user > (file:// uri in the current API) > > Is all of that still going to be possible? How? Listing calendars will look something like this: #include #include #include ESourceRegistry *registry; const gchar *extension_name; GList *sources; registry = e_source_registry_get_default (); /* List all calendars. */ extension_name = E_SOURCE_EXTENSION_CALENDAR; sources = e_source_registry_list_sources (registry, extension_name); /* Do something with the list of ESource objects. */ g_list_free (sources); Other extension names include: E_SOURCE_EXTENSION_ADDRESS_BOOK E_SOURCE_EXTENSION_MEMO_LIST E_SOURCE_EXTENSION_TASK_LIST No change to the way ECal and EBook objects are opened. Can you elaborate on the creation use case? Sounds like you're creating local data sources on the fly? ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Do, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote: > libebook > > - Remove e_book_new_from_uri() and e_book_get_uri(). > > - Remove e_book_get_addressbooks(). > > > libecal > --- > > - Remove e_cal_new_from_uri() and e_cal_get_uri(). > > - Remove e_cal_get_sources(). I must admit that I haven't read all of the emails due to lack of time. SyncEvolution uses all of these calls. I don't mind rewriting the code, but let's make sure that there is a proper replacement. What I need to do is: - list all address books and calendars - open any of the listed databases - create new ones at a location chose by the user (file:// uri in the current API) Is all of that still going to be possible? How? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Wed, 2011-01-26 at 06:17 +0100, Milan Crha wrote:
> thanks for doing this. I'm only wondering, why not a dot or dash (if
> available for bus names) between the version number and the bus name
> itself? Was there anything preventing it to do it that way? (I'm not
> much familiar with DBus itself, so please forgive me if this is a lame
> question.)
I would've preferred that myself, but apparently D-Bus (or just GDBus)
doesn't like digits after dots.
g_dbus_is_name ("blah.blah.Calendar.0") -> FALSE
g_dbus_is_name ("blah.blah.Calendar0") -> TRUE
I guess next time we bump the version you can stick a dash in there if
you want. "Calendar0" and "Calendar-0" are equally ugly to me.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Tue, 2011-01-25 at 16:54 -0500, Matthew Barnes wrote: > The new names are (with both versions at '0'): > >Bus Name:org.gnome.evolution.dataserver.AddressBook0 >Object Path: org/gnome/evolution/dataserver/AddressBookFactory >Interface: org.gnome.evolution.dataserver.AddressbookFactory > >Bus Name:org.gnome.evolution.dataserver.Calendar0 >Object Path: org/gnome/evolution/dataserver/CalendarFactory >Interface: org.gnome.evolution.dataserver.CalendarFactory Hi, thanks for doing this. I'm only wondering, why not a dot or dash (if available for bus names) between the version number and the bus name itself? Was there anything preventing it to do it that way? (I'm not much familiar with DBus itself, so please forgive me if this is a lame question.) Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Mon, 2010-11-15 at 11:45 -0500, Matthew Barnes wrote: > I kinda wanted to tweak the names anyway, so here's my proposal for the > new D-Bus interface names: > > Old: org.gnome.evolution.dataserver.addressbook.BookFactory >org.gnome.evolution.dataserver.calendar.CalFactory >org.gnome.evolution.dataserver.addressbook.Book >org.gnome.evolution.dataserver.calendar.Cal > > New: org.gnome.evolution.dataserver.AddressBookFactory.0 >org.gnome.evolution.dataserver.CalendarFactory.0 >org.gnome.evolution.dataserver.AddressBook.0 >org.gnome.evolution.dataserver.Calendar.0 > > In the future, if we have to break a D-Bus interface again we'll > increment the digit. Then if the user upgrades E-D-S to a version that > implements "Calendar.1" but is still running an e-calendar-factory that > implements "Calendar.0", then when Evolution is launched the session bus > will have to relaunch the upgraded e-calendar-factory binary and the old > e-calendar-factory process will lose its well-known D-Bus name (at least > I think that's how it works... in any case, D-Bus knows what to do). > > If there's no objections I'd like to get new interface names into 2.91 > now so I can increment the interface versions on my account-management > branch and not have to worry about this anymore. Milan reminded me about this today so I went ahead with it. It turns out just the D-Bus service names need to be versioned, not the interface names. But the same rules for incrementing the version apply. The new names are (with both versions at '0'): Bus Name:org.gnome.evolution.dataserver.AddressBook0 Object Path: org/gnome/evolution/dataserver/AddressBookFactory Interface: org.gnome.evolution.dataserver.AddressbookFactory Bus Name:org.gnome.evolution.dataserver.Calendar0 Object Path: org/gnome/evolution/dataserver/CalendarFactory Interface: org.gnome.evolution.dataserver.CalendarFactory More details in the commit message: http://git.gnome.org/browse/evolution-data-server/commit/?id=89b130c3d75cd0fa023af4064b0d0e3ce2147519 Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Tue, 2011-01-18 at 14:32 -0500, Matthew Barnes wrote: > Now I'll let you in on my master plan: Nice work Matt. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
Another status update: After much consideration I decided to drop GSettings from the equation and just access key files directly. The key file part of the design is working out well but I've been fighting with GSettings every step of the way. It's not that that GSettings is bad, but it's very much designed for dconf and not key files. Especially the way I'm using key files. The straw that broke the camel's back was in trying to figure out how to localize the display names of built-in top-level key files like "On This Computer" and "On LDAP Servers". The GSettings API has no equivalent to g_key_file_get_locale_string() so I was falling back to a similar hacky solution as e_source_list_ensure_group(). But with GSettings out of the way we can have the built-in key files translated through intltool just as we would for desktop files, and call g_key_file_get_locale_string() to get the appropriate localized display name. End result (this the 'system' key file): [Data Source] Parent=local DisplayName=Personal DisplayName[ar]=ﺶﺨﺼﻳ DisplayName[as]=ব্যক্তিগত DisplayName[ast]=Personal DisplayName[be]=Пэрсанальнае DisplayName[bg]=Лични DisplayName[bn]=ব্যক্তিগত DisplayName[bn_IN]=ব্যক্তিগত DisplayName[ca]=Personal displayname...@valencia]=personal DisplayName[cs]=Osobní DisplayName[cy]=Personol DisplayName[da]=Personligt DisplayName[de]=Persönlich DisplayName[dz]=རང་དོན། ...etc... I don't have translations yet for the other key files (the translations I need are all in Evolution, not E-D-S) but you get the idea. Note the key file syntax looks normal again and doesn't use GVariant quoting. Changes to the API I posted earlier [1] are minimal since the GSettings interaction was pretty well hidden. Obviously e_source_get_settings() is gone, as are the schema files. The schema for a key file group is instead derived from the GParamSpec structures of the corresponding ESourceExtension subclass. More about that later. [1] http://mail.gnome.org/archives/evolution-hackers/2010-December/msg00030.html ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Tue, 2010-12-21 at 10:14 +0100, Milan Crha wrote: > I like your idea. It might work as long as the backend is running, > otherwise it will not, unless you'll add a listener for this in factory > and run the backend if needed. I actually got it working last night for address books, although it required more API breaks in libedata-book (e_book_backend_remove() no longer takes an EDataBook or operation ID). Same type of problem exists now -- if the backend isn't running and you go into gconf-editor and manually delete tags, the cache data for those deleted sources will never get cleaned up. My thought was, after this is all done and merged and working, to have the backend processes scan their cache directories at start up and match the directory names to registered ESources, then clean up the unmatched "orphan" directories. The should fix the out-of-band deletion problem. We do the same sort of thing for old composer autosave files. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Mon, 2010-12-20 at 14:17 -0500, Matthew Barnes wrote: > Since removing an address book or calendar source will be as simple as > deleting its key file, in theory the backend process should be > notified of the file deletion event by its ESourceRegistry and can > then clean up after itself on its own without being told to by the > client. Hi, I like your idea. It might work as long as the backend is running, otherwise it will not, unless you'll add a listener for this in factory and run the backend if needed. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Thu, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote: > Overall the changes are having a simplifying effect on the code base, > but it will introduce an API break of some kind to almost every library > in E-D-S. That's what I wanted to talk about here. Couple more API breaks to mention which turned out to be happy accidents: we no longer need e_book_remove() or e_cal_remove(), nor the corresponding D-Bus methods. Both the e-addressbook-factory and e-calendar-factory processes will have their own ESourceRegistry instance, and ESourceRegistry monitors your "sources" directory for changes and emits "source-added" and "source-removed" signals in response to new or deleted key files. Since removing an address book or calendar source will be as simple as deleting its key file, in theory the backend process should be notified of the file deletion event by its ESourceRegistry and can then clean up after itself on its own without being told to by the client. I should get far enough to actually verify that today or tomorrow. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Sun, 2010-12-19 at 18:38 +, Rob Bradford wrote: > > Signals:void(*load_error) (ESourceRegistry *registry, > > GFile *file, > > GQuark error_domain, > > gint error_code, > > const gchar *error_message); > > There is obviously a reason why you wrote this .. but I can't see it. > Why can't you use const GError * here? I've been second guessing myself on that too. I think it was because I was worried someone would write a signal handler that improperly frees the GError, or propagates it, or some other memory-corrupting operation. But I guess I was just being overly paranoid. A const GError should work fine. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
>
> (I'm leaning away from having URI keys, favoring instead URI components
> as separate keys from which a complete URI string can be formed.)
As someone who's used ESource in the past .. I always found the old
way of doing it oh-so-confusing. I even added the following code to
dates:
/*
* Also ensure that the sources contained within this
* group have an appropriate uri setup. Removing the
* absolute uri in favour of a relative one.
*/
source_list = e_source_group_peek_sources (group);
for (GSList *source_list_it = source_list;
source_list_it != NULL;
source_list_it = g_slist_next
(source_list_it))
{
ESource *source = (ESource
*)source_list_it->data;
if (g_str_equal (e_source_peek_relative_uri
(source), ""))
{
const gchar *uri =
e_source_peek_absolute_uri (source);
gchar *path = g_filename_from_uri (uri,
NULL, NULL);
gchar *base_name = g_path_get_basename
(path);
e_source_set_absolute_uri (source,
NULL);
e_source_set_relative_uri (source,
base_name);
g_free (base_name);
g_free (path);
}
}
g_free (path);
g_free (new_uri);
Cheers,
Rob
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Fri, 2010-12-10 at 11:54 +0100, Milan Crha wrote:
> 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?
User name and authentication method will be stored in a key file group,
which defines the following keys (from my notes):
Schema: org.gnome.Evolution.Source.Authentication
--
[extensions/authentication]
--
domain : 's' (do we still need this?)
method : 's' ('none' means auth not required)
remember-password : 'b'
user: 's'
Both the user name and authentication method can be changed freely.
For a groupware account that shares authentication details across all
data sources, it would make sense to put the authentication group in the
top-level ESource alongside account details, then have child ESources
for mail accounts, calendars, etc. refer to it. The keyring entry for
the groupware account would store the UID of the top-level ESource so
the password too can be easily be shared across all data sources.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
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 evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
More brain dumping so this is all out in the open. Since I've been blathering on about this new ESource API and these "extension" things but haven't actually posted the API, I thought I should do so. Also attached are my notes for the GSettings schemas for these various ESourceExtension subclasses. Each subclass is really nothing more than a thin wrapper for GSettings keys from a particular schema. More detail about these later -- I'm still tweaking them. ESource === Properties: "backend" : gchararray(read/write) "file" : GFile * (construct-only) "name" : gchararray(read/write) "settings" : GSettings * (read-only) "uid" : gchararray(read-only) Signals:void (*changed) (ESource *source); Functions: GType e_source_get_type (void) G_GNUC_CONST; ESource * e_source_new(GFile *file, GError **error); guint e_source_hash (ESource *source); gbooleane_source_equal (ESource *source1, ESource *source2); voide_source_changed(ESource *source); const gchar * e_source_get_uid(ESource *source); GFile * e_source_get_file (ESource *source); GNode * e_source_get_node (ESource *source); const gchar * e_source_get_name (ESource *source); voide_source_set_name (ESource *source, const gchar *name); const gchar * e_source_get_backend(ESource *source); voide_source_set_backend(ESource *source, const gchar *backend); GSettings * e_source_get_settings (ESource *source); gpointere_source_get_extension (ESource *source, const gchar *name); gbooleane_source_has_extension (ESource *source, const gchar *name); ginte_source_compare_by_name(ESource *source_a, ESource *source_b); ESourceExtension Properties: "settings" : GSettings * (read-only) "source": ESource * (construct-only) Signals:(none) Class Data: const gchar *name; /* extension name */ const gchar *schema;/* GSettings schema */ Functions: GType e_source_extension_get_type (void) G_GNUC_CONST; ESource * e_source_extension_get_source (ESourceExtension *extension); GSettings * e_source_extension_get_settings (ESourceExtension *extension); ESourceRegistry === Properties: (none) Signals:void(*load_error) (ESourceRegistry *registry, GFile *file, GQuark error_domain, gint error_code, const gchar *error_message); void(*source_added) (ESourceRegistry *registry, ESource *source); void(*source_changed) (ESourceRegistry *registry, ESource *source); void(*source_removed) (ESourceRegistry *registry, ESource *source); Functions: GType e_source_registry_get_type (void) G_GNUC_CONST; ESourceRegistry * e_source_registry_new (void); ESourceRegistry * e_source_registry_get_default (void); voide_source_registry_add_source(ESourceRegistry *registry); voide_source_registry_remove_source (ESourceRegistry *registry); gbooleane_source_registry_load_sources (ESourceRegistry *registry, GError **error); gbooleane_source_registry_load_directory (ESourceRegistry *registry, const gchar *path, GError **error); ESource * e_source_registry_load_file (ESourceRegistry *registry, GFile *file, GError **error); ESource * e_source_registry_lookup_by_file (ESourceRegistry *registry, GFile *file); ESource * e_source_reg
Re: [Evolution-hackers] Rethinking account management
Here's a progress update on my account management rewrite. I've been on travel for the past three weeks and still have another week to go, so I've only been able to work on this in short spurts -- an hour here, an hour there. But I've managed to work through all of E-D-S, get the test-source-combo-box and test-source-selector programs working with the keyfile-based ESources, and am now plowing my way through Evolution itself. 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. Overall the changes are having a simplifying effect on the code base, but it will introduce an API break of some kind to almost every library in E-D-S. That's what I wanted to talk about here. I'm still only on address books and calendars. For mail accounts, EAccountList will die and EAccount will be split into two separate key files (one for "store" settings, one for "transport" settings). Beyond that I don't anticipate many (if any) more API breaks in E-D-S for mail accounts. For address books and calendars, ESourceList and ESourceGroup will die (replaced by an ESourceRegistry singleton which holds everything). The ESource API will be rewritten from scratch, will no longer use GConf and also will no longer have a URI. All other API breaks follow from that. So here's what I've broken on my branch so far, grouped by library: libedataserver -- - Remove ESourceList and ESourceGroup. - Rewrite ESource from scratch. libebook - Remove e_book_new_from_uri() and e_book_get_uri(). - Remove e_book_get_addressbooks(). libecal --- - Remove e_cal_new_from_uri() and e_cal_get_uri(). - Remove e_cal_get_sources(). - ECalAuthFunc: the 'key' argument is no longer used. libedata-cal - Remove e_cal_backend_get_uri(). 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). - ESourceComboBox will take an ESourceRegistry and an extension name as constructor arguments. The given extension name will filter the sources shown in the widget (e.g. "address-book", "calendar", etc.). - Similarly for ESourceSelector. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
Hi, On Mon, 2010-11-15 at 11:45 -0500, Matthew Barnes wrote: > I was a bit horrified to realize over the weekend the way we select a > backend from the factory processes when requesting a new EBook or ECal. > We convert an ESource object to XML and transmit the -entire- XML string > over D-Bus, only to have the factory process reconstruct the ESource > object from the XML string, extract the URI string from the ESource > object, and extract the scheme from the URI. The scheme is used as a > hash table key for registered backends. Well, it's not complete, the reconstructed ESource is passed into e_data_book_new, so the backend can access it and knows where to connect. > With the new APIs, apart from GConf migration we won't be constructing > ESources from XML anymore. So here's how it's gonna work: getCal() and > getBook() will just take the ESource's UID string, the factory process > will look up the corresponding ESource object from its own registry and > call e_source_get_backend() to get the hash table key. Done. That's kinda limiting, isn't it? As you allow only saved sources to be opened, though for example all test suits are not saving their sources, but just construct them on the fly and pass them to the factory. > ... > If there's no objections I'd like to get new interface names into 2.91 > now so I can increment the interface versions on my account-management > branch and not have to worry about this anymore. Sounds fine to me. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
Let's talk D-Bus. I've started integrating the redesigned, key-file based ESource APIs in a branch of Evolution-Data-Server and so far it's actually simplifying the affected code. I'm leaving mail aside for now and just focusing on calendars and address books. I'm gonna have to remove some functions from libebook and libecal which don't make sense anymore. More about those later. But I also realized I'm gonna have to change the getCal() and getBook() D-Bus methods. I was a bit horrified to realize over the weekend the way we select a backend from the factory processes when requesting a new EBook or ECal. We convert an ESource object to XML and transmit the -entire- XML string over D-Bus, only to have the factory process reconstruct the ESource object from the XML string, extract the URI string from the ESource object, and extract the scheme from the URI. The scheme is used as a hash table key for registered backends. Holy convoluted design, Bat Man! With the new APIs, apart from GConf migration we won't be constructing ESources from XML anymore. So here's how it's gonna work: getCal() and getBook() will just take the ESource's UID string, the factory process will look up the corresponding ESource object from its own registry and call e_source_get_backend() to get the hash table key. Done. That part's easy. What I'm concerned about is avoiding a repeat of the issues we encountered last cycle when we changed the local backend name from "file" to "local". In particular, we need to make sure the client and servers are using the same D-Bus API at run time. This is proving to be a real problem as users upgrade from Evolution 2.30 to 2.32 but leave the factory processes from 2.30 running. There's some debate about the best way to handle D-Bus API changes, but after talking to a few colleagues it seems the simplest approach is to append a digit to the interface name, like we do for shared libraries. I kinda wanted to tweak the names anyway, so here's my proposal for the new D-Bus interface names: Old: org.gnome.evolution.dataserver.addressbook.BookFactory org.gnome.evolution.dataserver.calendar.CalFactory org.gnome.evolution.dataserver.addressbook.Book org.gnome.evolution.dataserver.calendar.Cal New: org.gnome.evolution.dataserver.AddressBookFactory.0 org.gnome.evolution.dataserver.CalendarFactory.0 org.gnome.evolution.dataserver.AddressBook.0 org.gnome.evolution.dataserver.Calendar.0 In the future, if we have to break a D-Bus interface again we'll increment the digit. Then if the user upgrades E-D-S to a version that implements "Calendar.1" but is still running an e-calendar-factory that implements "Calendar.0", then when Evolution is launched the session bus will have to relaunch the upgraded e-calendar-factory binary and the old e-calendar-factory process will lose its well-known D-Bus name (at least I think that's how it works... in any case, D-Bus knows what to do). If there's no objections I'd like to get new interface names into 2.91 now so I can increment the interface versions on my account-management branch and not have to worry about this anymore. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Wed, 2010-11-10 at 16:20 -0500, Matthew Barnes wrote: > On Thu, 2010-11-11 at 09:16 +1300, Andrew McMillan wrote: > > Does this mean (for example) that we will be able to have a caldav > > server, with credentials, and then just associate (and maybe > > auto-discover) all of the user's addressbooks, calendars, todo-lists and > > journals which the user has on that server? > > I honestly don't know if that's possible with a CalDAV server (I'm just > not familiar enough with CalDAV), but if we're talking about a groupware > service... Yes, it is. Apple iCal (for example) will discover and show all of a user's calendar collections. The contacts app on an iPhone (with iOS 4.1) will discover and show all of a user's addressbooks if that DAV server also does CardDAV. Calendar collections may very well also store VTODO and VJOURNAL data (DAViCal does, for example, as well as supporting CardDAV in very recent versions). So Evolution, with SMTP, IMAP, CalDAV and CardDAV servers really is a complete groupware service. Newer extensions to CalDAV/CardDAV also add support for service discovery through SRV lookups for _caldav, _caldavs, _carddav, _carddavs services and URL locating through requests against /.well-known/carddav or /.well-known/caldav URLs after the server discovery. > Currently each of our groupware backends has to invent this kind of > account management for itself. All I'm proposing is a general framework > that backends can utilize to make it easier and more consistent. > > Auto-discovery is also up to each backend to implement, and rightfully > so. But the framework certainly allows for discovered data sources to > be associated with the account. > > I hope I answered your question. Like I said, handling of groupware > accounts is still kinda hand wavy at this point. I think so. Evolution was early to the party when CalDAV came out as a specification, but the support in there has not evolved very well to follow the current possibilities. That said, the biggest complaint I hear about Evolution's CalDAV support is it's lack of a useful 'offline' mode. I'm currently in the process of developing caldav/carddav setup and synchronisation process (for another purpose) but once that's working it might be worth looking at that with a view to seeing if we can improve the structure of CalDAV setup within Evolution. I know Milan has done some good work on CalDAV (and I'm very grateful for it) but I think the area needs some significant refactoring in the configuration and discovery parts. My biggest annoyance in there is that I go into a calendar and add a CalDAV server, and a collection, and then I go into tasks and add *the same* server, and *the same* collection, and then I go into Notes and add *the same server* and *the same collection* and then I go into the addressbook and add *the same server*, and (phew!) a different collection. There seems a little redundancy in that process, not least because for a given server I can discover all of a user's calendars and addressbooks, and whether they support calendar, tasks and/or notes by making two PROPFIND requests. Or maybe three requests, for a more recent server that allows discovery of the principal URL. Cheers, Andrew. -- http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN The real problem with hunting elephants is carrying the decoys. signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Thu, 2010-11-11 at 08:55 +0100, Milan Crha wrote: > Will be there any kind of property inheritance? As in your example > above, I would like to define the 'color' in the [source] > key-file-group, thus all extensions will inherit it, but, if user > changes color for one of them, then it'll create its own key and it will > be used instead of the parent's. Certain keys can be inherited, yes. We've already seen inheritance in some examples I gave with the 'backend' key. Another example might be an 'enabled' key, which could work similar to widget visibility in that a child source may have enabled=true, but it's not -really- enabled unless all of its parent sources are also enabled. > Maybe it's not the best example with the color, but imagine the Exchange > account, I would like to define server address and credentials, > connection setup and such, in the parent, and the children > (mail/calendar/...) will inherit this. I imagine that too. I think groupware backends will have considerable freedom to distribute information across sources however they want. The API isn't nearly finished yet, but at the moment I'm thinking of embedding a GNode within each ESource object to represent the source's position in the hierarchy. The GNode's data value would point back to its ESource object, so you can access parent, sibling or child sources through the GNode API. For example, fetching account information from a parent source might look something like: /* Suppose ExchangeAccount wraps a GSettings object that * manages an [extensions/exchange-account] group in the * parent of a calendar source. The "exchange-account" * group holds the server address, credentials, etc. */ ExchangeAccount *account; ESource *parent; GNode *node; node = e_source_get_node (calendar_source); parent = E_SOURCE (node->parent->data); account = e_source_get_extension (parent, "exchange-account"); /* This retrieves the value of: * * [extensions/exchange-account] * hostname='my.exchange.server.com' */ hostname = exchange_account_get_hostname (account); > Imagine the exchange account again. Right now you define an account > name, and this name is used as a source group name in Calendar and such, > same as in mailer. With that you wrote I do not see a way of achieve > that just from the user's home. Or is this based on the existence of the > parent/backend key in the [source] key-file-group? In that case the > exchange account will have actually two files instead of one in the home > directory, one for group definition and one for real sources? It's > unnecessary, right? a) you would search for parents, in home and in > system directory. b) you should be able to easily distinguish between > group definitions and real sources definitions (all are named [source] > in your proposal) and be able to _easily_ reconstruct them. A groupware account will likely consist of a collection of key files, but you won't be interacting with key files directly, as shown above. Some central ESource registry will load all the key files, create an ESource object for each of them, arrange them in a hierarchy, and emit signals when the "sources" directory changes. > Also, remember that users can name their accounts whatever they want, > but not every latter is usable for the filename - so the files will be > either meaningless strings or something descriptive? Built-in sources can have meaningful UIDs like "on-this-computer" or "on-the-web", since those key files will be installed as part of the E-D-S package. User-created sources will use the same generated UID strings that we're using now, via e_uid_new(). > The last two questions (and I see I mostly answered above questions > myself), how will be the group definition propagated to mailer, > respectively how will be defined the POP account, which doesn't have a > group in the folder tree, same as the mbox, which is hacked in and > hidden in the background? Will these two kinds also require its own > group file (for the 'backend' key) or not? A pop account would look something like: [source] name='My POP Account' parent='on-this-computer' backend='pop' [extensions/mail] ... account details ... The folder tree will have to give special treatment to accounts that rely on the built-in local mail store, but we already do that. > Because you have [source] for groups and [source] for pseudo-sources > (the real source is at the [extension/...]), then will I be able to > define a child of the source, not of the group, and it'll be propagated > to the UI? Just an idea, not that I think it would be usable. I'm purposefully leaving the file format very open-ended and flexible. The API will be less so. There's all kinds of key file configurations you can think up that Evolution can't support right now. We can either decide it's an invalid configuration, or perhaps it could lead to a new feature. That's why I'm leaving it open-ended. Hopefully
Re: [Evolution-hackers] Rethinking account management
On Wed, 2010-11-10 at 11:39 -0500, Matthew Barnes wrote: > Here's a few built-in top-level stub sources as trivial examples. They > don't do anything other than name a backend. They would appear as bold > group names in a source selector widget. > > 1. Filename/UID: "on-this-computer" > > [source] > name='On This Computer' > backend='local' > > > The built-in "system" (a.k.a. Personal) source is an interesting corner > case because it defines several different groups. (The comments below > are just my annotations, they would not appear in the key file.) > > Filename/UID: system > > [source]# org.gnome.Evolution.Source > name='Personal' > parent='on-this-computer' > > [extensions/address-book] # org.gnome.Evolution.Source.Selectable > color='#00' # would not be used in the UI > enabled=true# would not be used in the UI > > [extensions/calendar] # org.gnome.Evolution.Source.Selectable > color='#becedd' > enabled=true > > [extensions/task-list] # org.gnome.Evolution.Source.Selectable > color='#becedd' > enabled=false > > [extensions/memo-list] # org.gnome.Evolution.Source.Selectable > color='#becedd' > enabled=false Hi, it's pretty confusing to me. I understand from the above that there are two files, one for groups, which is stored in system directory, and "one" for real sources, which is stored in user's home. Will be there any kind of property inheritance? As in your example above, I would like to define the 'color' in the [source] key-file-group, thus all extensions will inherit it, but, if user changes color for one of them, then it'll create its own key and it will be used instead of the parent's. Maybe it's not the best example with the color, but imagine the Exchange account, I would like to define server address and credentials, connection setup and such, in the parent, and the children (mail/calendar/...) will inherit this. It seems to me that there is no difference between the file in system and home directory, both are using [source], but each for a different purpose. I do not think it may work well. Imagine the exchange account again. Right now you define an account name, and this name is used as a source group name in Calendar and such, same as in mailer. With that you wrote I do not see a way of achieve that just from the user's home. Or is this based on the existence of the parent/backend key in the [source] key-file-group? In that case the exchange account will have actually two files instead of one in the home directory, one for group definition and one for real sources? It's unnecessary, right? a) you would search for parents, in home and in system directory. b) you should be able to easily distinguish between group definitions and real sources definitions (all are named [source] in your proposal) and be able to _easily_ reconstruct them. Well, it's not straightforward, from my point of view. I would rather name groups [group], avoid confusion, and be able to define all this in one file, thus for usual user they will be able to distribute only one file with predefined account settings instead of many. Of course, the groups should either have the 'uid' defined in the file, or it should "inherit" uid from the file name itself. Filename: excha...@my-company [group] name='excha...@my-company' backend='exchange' server='my-company' username='me' [source] color='#FEFEEF' parent='excha...@my-company' [extensions/mail] enabled=true [extensions/addressbook] fragment='personal/Contacts' name='Contacts' [extensions/addressbook] fragment='personal/second-contacts' name='second-contacts' [extensions/calendar] fragment='personal/Calendar' name='Calendar' last-notified='2010-10-10T10:10:10' [extensions/calendar] fragment='personal/second-calendar' name='Second Calendar' color='#80FF80' ... Well, you cannot have two groups with the same name in the key file, thus you really meant to have one file per each ESource/EAccount + one file for the group definition, all these put into one folder in the home (+ system group definitions in system folder)? I do not like the idea much, but I agree it can work. Also, remember that users can name their accounts whatever they want, but not every latter is usable for the filename - so the files will be either meaningless strings or something descriptive? The last two questions (and I see I mostly answered above questions myself), how will be the group definition propagated to mailer, respectively how will be defined the POP account, which doesn't have a group in the folder tree, same as the mbox, which is hacked in and hidden in the background? Will these two kinds also require its own group file (for the 'backend' key) or not? Because you have [source] for groups and [source] for pseudo-sources (the real source is at the [extension/...]), then will I be able to define a child of the source, not of the group,
Re: [Evolution-hackers] Rethinking account management
On Wed, 2010-11-10 at 11:39 -0500, Matthew Barnes wrote: > As part of our transition from GConf to GSettings, which Rodrigo Moya > has graciously been helping with, I've put some thought into addressing > the XML string lists which we currently store in GConf under "accounts" > and "sources" keys. We've known for years that this is a really bad > approach, and I don't think I have to enumerate the reasons why. > > To this day many users assume they can backup or copy their Evolution > accounts by simply archiving or copying their Evolution data directory, > and no amount of repetition about the "correct" way to do it seems to > stick. And predictably so. Correcting people's reasonable expectation > of how something works is about as futile as getting them to say "GNU > slash Linux". So my take on the problem is to invoke the Principle of > Least Astonishment and make account storage work the way users assume it > does. Copying accounts from one machine to another -ought- to be as > simple as copying files in your Evolution data directory. > > I propose we use key files. Specifically a hierarchy of key file based > GSettings objects, which I'll elaborate on. I also propose we throw out > the current EAccount and ESource classes (along with the group and list > container classes) and unify them under a common framework. The next > release is called 3.0 so this is as good a time as any for a major API > break in libedataserver. > > For lack of a better word I'm reusing the term "source" to describe the > key files, but with a slightly different definition. A source is simply > a node in a hierarchy of sources. A source may describe a mail account, > an address book, a calendar, a task list or memo list (or a combination > thereof), or it may simply be a stub under which other sources are > grouped. > > The key files for these sources will live in two "sources" directories: > a system wide directory for built-in sources and a user directory for > custom sources. For example: > > /usr/share/evolution-data-server-3.0/sources # built-in sources > > $HOME/.local/share/evolution/sources # custom sources > > The user's "sources" directory will be monitored for changes, so adding > or removing a custom source will be as simple as creating or removing a > file in that directory. Evolution will see it and respond accordingly. > > In theory this should allow source creation tools such as the mail > account capplet to be written as standalone programs that don't depend > on Evolution APIs. Such tools would just drop a properly formatted key > file in the "sources" directory, and Evolution will see the new key file > and automatically present the new source in its user interface. > > I'm still designing the APIs for this, but I think I have the file > format and GSettings mappings pretty much finished so I'll just talk > about that. More details about the API to follow. > > A source's UID is the base name of its key file. At minimum, the > content of a key file consists of a [source] group conforming to the > relocatable "org.gnome.Evolution.Source" schema, which defines the > following keys: > > org.gnome.Evolution.Source > -- > "name" (string, required) The source's UTF-8 display name. > "parent" (string, optional) The UID of the parent source, if any. > "backend" (string, optional) The backend which handles the source. > > The corresponding GSettings paths would be: > > /org/gnome/evolution/sources/<>/name > /org/gnome/evolution/sources/<>/parent > /org/gnome/evolution/sources/<>/backend > > Here's a few built-in top-level stub sources as trivial examples. They > don't do anything other than name a backend. They would appear as bold > group names in a source selector widget. > > 1. Filename/UID: "on-this-computer" > > [source] > name='On This Computer' > backend='local' > > 2. Filename/UID: "on-ldap-servers" > > [source] > name='On LDAP Servers' > backend='ldap' > > 3. Filename/UID: "google" > > [source] > name='Google' > backend='google' > > 4. Filename/UID: "caldav" > > [source] > name='CalDAV' > backend='caldav' > > The key file format is extensible. The file can define additional > groups, each with its own schema. Each group is managed by a different > GSettings instance, but they share a common key file backend. > > This is how a source identifies itself as a mail account, a calendar, a > task list, etc. Plugins can even get in on the act, defining their own > group and schema for, say, per-account mail notification options (as a > hypothetical). > > The built-in "system" (a.k.a. Personal) source is an interesting corner > case because it defines several different groups. (The comments below > are just my annotations, they would not appear in the key file.) > > Filename/UID: system > > [source]# org.gnom
Re: [Evolution-hackers] Rethinking account management
On Thu, 2010-11-11 at 09:16 +1300, Andrew McMillan wrote: > Does this mean (for example) that we will be able to have a caldav > server, with credentials, and then just associate (and maybe > auto-discover) all of the user's addressbooks, calendars, todo-lists and > journals which the user has on that server? I honestly don't know if that's possible with a CalDAV server (I'm just not familiar enough with CalDAV), but if we're talking about a groupware service where, for example, suppose I have a Microsoft Exchange account consisting of an email store, a calendar, a to-do list and a couple address books; then with this proposal we can now express a hierarchical relationship between those different data sources and treat them within Evolution as a single "account", such that I can disable or delete my Exchange mail account in Preferences and all the other data sources for that account will automatically follow. Currently each of our groupware backends has to invent this kind of account management for itself. All I'm proposing is a general framework that backends can utilize to make it easier and more consistent. Auto-discovery is also up to each backend to implement, and rightfully so. But the framework certainly allows for discovered data sources to be associated with the account. I hope I answered your question. Like I said, handling of groupware accounts is still kinda hand wavy at this point. Gotta get the simple cases working first. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Wed, 2010-11-10 at 11:39 -0500, Matthew Barnes wrote: > > Backends can also define their own groups and schemas for storing > settings that are specific to that backend. Here's an off-the-cuff > example of what a source describing a CalDAV calendar might look like: > > [source]# org.gnome.Evolution.Source > name='My Calendar' > parent='caldav' > > [extensions/calendar] # org.gnome.Evolution.Source.Selectable > color='#e2f0d3' > enabled=true > > [extensions/caldav] # org.gnome.Evolution.Source.CalDAV > host='my.caldav.provider' > user='mbarnes' > path='/dav/mbarnes/Calendar' > ssl=true > ... > > (I'm leaning away from having URI keys, favoring instead URI components > as separate keys from which a complete URI string can be formed.) > > Here's where the hierarchy concept gets powerful. The source structure > for a groupware account providing integrated mail, calendars, contacts > (this is Exchange, GroupWise, perhaps someday Zimbra and Kolab, etc.) > might be a top-level source with groups defining a mail account with > server info and also any calendars or address books that you get by > default on the groupware account. Additional calendars or address books > or public mail folders for you or even other users on the server could > be implemented as child sources, such that disabling or deleting the > top-level mail account source affects the entire subtree of sources. Does this mean (for example) that we will be able to have a caldav server, with credentials, and then just associate (and maybe auto-discover) all of the user's addressbooks, calendars, todo-lists and journals which the user has on that server? > This is getting a little hand wavy now because I've only just figured > out the file format and groupware integration is a ways off. But I hope > you can kinda see where I'm going with this and recognize its value over > what we have now. If what you're suggesting aligns with what I'm understanding, then the word "hallelujah" springs to mind :-) Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Don't engineer in a crisis. -- Vint Cerf speaking on IPv6 signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Rethinking account management
As part of our transition from GConf to GSettings, which Rodrigo Moya has graciously been helping with, I've put some thought into addressing the XML string lists which we currently store in GConf under "accounts" and "sources" keys. We've known for years that this is a really bad approach, and I don't think I have to enumerate the reasons why. To this day many users assume they can backup or copy their Evolution accounts by simply archiving or copying their Evolution data directory, and no amount of repetition about the "correct" way to do it seems to stick. And predictably so. Correcting people's reasonable expectation of how something works is about as futile as getting them to say "GNU slash Linux". So my take on the problem is to invoke the Principle of Least Astonishment and make account storage work the way users assume it does. Copying accounts from one machine to another -ought- to be as simple as copying files in your Evolution data directory. I propose we use key files. Specifically a hierarchy of key file based GSettings objects, which I'll elaborate on. I also propose we throw out the current EAccount and ESource classes (along with the group and list container classes) and unify them under a common framework. The next release is called 3.0 so this is as good a time as any for a major API break in libedataserver. For lack of a better word I'm reusing the term "source" to describe the key files, but with a slightly different definition. A source is simply a node in a hierarchy of sources. A source may describe a mail account, an address book, a calendar, a task list or memo list (or a combination thereof), or it may simply be a stub under which other sources are grouped. The key files for these sources will live in two "sources" directories: a system wide directory for built-in sources and a user directory for custom sources. For example: /usr/share/evolution-data-server-3.0/sources # built-in sources $HOME/.local/share/evolution/sources # custom sources The user's "sources" directory will be monitored for changes, so adding or removing a custom source will be as simple as creating or removing a file in that directory. Evolution will see it and respond accordingly. In theory this should allow source creation tools such as the mail account capplet to be written as standalone programs that don't depend on Evolution APIs. Such tools would just drop a properly formatted key file in the "sources" directory, and Evolution will see the new key file and automatically present the new source in its user interface. I'm still designing the APIs for this, but I think I have the file format and GSettings mappings pretty much finished so I'll just talk about that. More details about the API to follow. A source's UID is the base name of its key file. At minimum, the content of a key file consists of a [source] group conforming to the relocatable "org.gnome.Evolution.Source" schema, which defines the following keys: org.gnome.Evolution.Source -- "name" (string, required) The source's UTF-8 display name. "parent" (string, optional) The UID of the parent source, if any. "backend" (string, optional) The backend which handles the source. The corresponding GSettings paths would be: /org/gnome/evolution/sources/<>/name /org/gnome/evolution/sources/<>/parent /org/gnome/evolution/sources/<>/backend Here's a few built-in top-level stub sources as trivial examples. They don't do anything other than name a backend. They would appear as bold group names in a source selector widget. 1. Filename/UID: "on-this-computer" [source] name='On This Computer' backend='local' 2. Filename/UID: "on-ldap-servers" [source] name='On LDAP Servers' backend='ldap' 3. Filename/UID: "google" [source] name='Google' backend='google' 4. Filename/UID: "caldav" [source] name='CalDAV' backend='caldav' The key file format is extensible. The file can define additional groups, each with its own schema. Each group is managed by a different GSettings instance, but they share a common key file backend. This is how a source identifies itself as a mail account, a calendar, a task list, etc. Plugins can even get in on the act, defining their own group and schema for, say, per-account mail notification options (as a hypothetical). The built-in "system" (a.k.a. Personal) source is an interesting corner case because it defines several different groups. (The comments below are just my annotations, they would not appear in the key file.) Filename/UID: system [source]# org.gnome.Evolution.Source name='Personal' parent='on-this-computer' [extensions/address-book] # org.gnome.Evolution.Source.Selectable color='#00' # would not be used in the UI enabled=true# would not be used in the UI [extensions/calendar]
