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,
[Evolution-hackers] configure issue with e-d-s and evolution
In evolution-data-server if you want to build without the weather utility you pass --without-weather. But in evolution if you want to build without weather built in you pass --disable weather. Doh!! Can someone fix these to be consistent with each other? Thanks. ___ 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: > 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]
