Re: [Evolution-hackers] [evolution-kolab] On porting and extending the plugin
Hi all, thanks to Matt, here are another two which I initially missed (since I was much clear that Camel would move to GObject/GError/GIO...): -- Thread: http://mail.gnome.org/archives/evolution-hackers/2009-November/msg00019.html "[Evolution-hackers] Camel Manifesto" http://mail.gnome.org/archives/evolution-hackers/2010-May/msg0.html "Re: [Evolution-hackers] Camel Manifesto (update)" Objective: * Camel moving from CamelObject to GObject * the former Camel type system is removed * introducing Camel async API * ... evolution-kolab affected classes: * CamelIMAPX* * CamelKolabIMAPX* * KolabMailImapClient * (potentially) KolabMailMimeBuilder -- Thread: http://mail.gnome.org/archives/evolution-hackers/2010-July/msg00025.html "[Evolution-hackers] Heads Up: More Camel API breakage in 2.31" Objective: * Camel moving from CamelException to GError * G_IO_ERROR for failable disk/net Camel operations evolution-kolab affected classes: * CamelIMAPX* * CamelKolabIMAPX* * KolabMailImapClient * (potentially) KolabMailMimeBuilder -- -- 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] [evolution-kolab] On porting and extending the plugin
Hi all. Am Dienstag 13 September 2011, um 15:56:00 schrieb Christian Hilberg: > The evolution-kolab team is currently planning to port the evolution-kolab > plugin to the recent developer version of Evo/E-D-S. I have had a discussion > [...] In order to get a clearer picture of the changes in Evo and E-D-S since version 2.30, I have been groveling through the list postings in search for major changes which will affect the porting (and later extending) of evolution-kolab. I have condensed my findings into a text file which I found might be helpful for others as well, so I'm posting it here. It is evolution-kolab centric of course, and it leaves out all changes which do not affect an E-D-S plugin, also it may not be exhaustive. But hey, you get it free of charge. ;-) Here it is, have fun: evolution-kolab - major Evo/EDS changes since 2.30 created:2011-09-13 Christian Hilberg changed:2011-09-14 Christian Hilberg Camel -- Thread: http://mail.gnome.org/archives/evolution-hackers/2010-September/msg00037.html "Re: [Evolution-hackers] Camel Manifesto (update)" Objective: * Redefinition of CamelOperation * Rename blocking methods * Asynchronous Methods (new asynchronous API) * CamelStream API change evolution-kolab affected classes: * KolabMailImapClient * everything using CamelStreamMem -- Thread: http://mail.gnome.org/archives/evolution-hackers/2011-April/msg00093.html "[Evolution-hackers] CamelService changes" Objectives: * new Camel XDG file system layout * CamelService, CamelSession API changes evolution-kolab affected classes: * CamelKolabSession * CamelKolabStore * KolabMailImapClient -- Thread: http://mail.gnome.org/archives/evolution-hackers/2011-June/msg00016.html "[Evolution-hackers] Rethinking Camel settings" Objectives: * introduction of CamelSettings class * settings propagation through Camel classes * plans for "binding mail account settings to ESourceExtensions" evolution-kolab affected classes: * CamelIMAPX* * CamelKolab* -- Evo / EDS (non-Camel) -- Thread: http://mail.gnome.org/archives/evolution-hackers/2010-November/msg00013.html "[Evolution-hackers] Rethinking account management" Objective: * move from GConf to key files (details key file layout) * establish ESourceRegistry (monitoring of config changes) * rewrite of ESource*, API change * connect backend-discovered sources with account evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab -- Thread: http://mail.gnome.org/archives/evolution-hackers/2010-November/msg00054.html "[Evolution-hackers] Account management and keyrings" Objective: * integration of GNOME keyring with the new account management handling * password handling and storing in ESource / EAccount * ESource password API for frontend/backend use evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab -- Thread: http://mail.gnome.org/archives/evolution-hackers/2011-January/msg4.html "[Evolution-hackers] Install E-D-S backends into separate directories?" Objective: * separate installation directories for calendar and address book backends * issues with GTypeModule and backend type registering * ESource interferences with GTypeModule (and solving strategy) evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab -- Thread: http://mail.gnome.org/archives/evolution-hackers/2011-March/msg00064.html "[Evolution-hackers] Front-end header files for E-D-S libraries" Objective: * create toplevel header files for each E-D-S library * deprecate inclusion of individual lower-level headers evolution-kolab affected classes: * potentially all -- Thread: http://mail.gnome.org/archives/evolution-hackers/2011-March/msg00075.html "[Evolution-hackers] Backend requesting arbitrary user input from frontend" Objective: * how to allow backends to ask for user data * case at hand: user PIN (cannot be stored) * signaling from backend to frontend to request for data evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab * KolabMailImapClient -- Thread: http://mail.gnome.org/archives/evolution-
Re: [Evolution-hackers] CamelService changes
On Wed, 2011-09-14 at 16:43 +0200, Christian Hilberg wrote: > Please forgive me for not reading the Camel code here - can one guess > from the UID to which account it may belong? Yes, in fact it's trivial now: CamelService.uid == EAccount.uid > What's more, in the current evolution-kolab design for 2.30, we have > > $(XDG_DATA_HOME)/evolution/mail/$(PROVIDER_NAME)/$(URL) > $(XDG_DATA_HOME)/evolution/calendar/$(PROVIDER_NAME)/$(URL) > $(XDG_DATA_HOME)/evolution/addressbook/$(PROVIDER_NAME)/$(URL) > > since we're using CamelStore also in the backends. Hope this will not prove > a broken design with the new situation for Camel. We'll be moving to UID-based directory names across the board for 3.4: $(XDG_DATA_HOME)/evolution/mail/$(UID) $(XDG_DATA_HOME)/evolution/calendar/$(UID) $(XDG_DATA_HOME)/evolution/addressbook/$(UID) ___ 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] CamelService changes
Hi there, I know it is muc hlate for input, but anyway, here we go: Am Donnerstag 21 April 2011, um 18:43:27 schrieb Matthew Barnes: > To help smooth the way for the account-mgmt I've made a few improvements > to the CamelSession and CamelService APIs in 3.1. It's not necessarily > the *final* APIs that will wind up in 3.2, but more like the first round > of changes leading up to 3.2. > [...] > * The file storage location for CamelServices (really only CamelStores) > has changed. It is now simply: > > $(XDG_DATA_HOME)/evolution/mail/$(UID) > > rather than: > > $(XDG_DATA_HOME)/evolution/mail/$(PROVIDER_NAME)/$(URL) > > That means each CamelService has a permanent location for files that > doesn't change if the user tweaks server settings or even changes the > provider. > [...] I recall that when I tried to find my way into Camel when using it from within the backend processes for evolution-kolab, I screwed up my provider directory (named 'kolab2' in 2.30) now and then because of wrong Camel use. It was then very easy to recover from the error by just killing my own provider's subdirectory, which was easy to identify (let alone all of the downsides the historic approach may have). Please forgive me for not reading the Camel code here - can one guess from the UID to which account it may belong? What's more, in the current evolution-kolab design for 2.30, we have $(XDG_DATA_HOME)/evolution/mail/$(PROVIDER_NAME)/$(URL) $(XDG_DATA_HOME)/evolution/calendar/$(PROVIDER_NAME)/$(URL) $(XDG_DATA_HOME)/evolution/addressbook/$(PROVIDER_NAME)/$(URL) since we're using CamelStore also in the backends. Hope this will not prove a broken design with the new situation for Camel. Moreover, our pimped IMAPX derivative uses further SQLite databases in addition to the folders.db Camel creates. These are for Kolab metadata and for an offline write cache for Kolab PIM data. The PIM data cache is used in backend context only, while the Kolab folder metadata DB is used by the kolab2 provider run in Evo as well. I hope that changing forth and back the providers for an account will not mess with that. (The Kolab metadata DB is re-created and re-populated in case it is missing, so it should not be problematic during migration.) 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
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] SyncEvolution + EClient API + EXDATE regression (Bug #655253)
On Wed, 2011-09-14 at 09:50 +0200, Patrick Ohly wrote: > On Mi, 2011-09-14 at 08:28 +0200, Milan Crha wrote: > > yes, I agree, it wasn't the right change, I'm sorry for that. Please > > revert the commit and reopen the bug. > > I reverted the EXDATE part of the commit, but couldn't reopen the bug > (Bugzilla does't offer me that option). Can you reopen it? Hi, thanks. I see Akhil took care of the reopen. And now just find the proper solution (and possibly when it got broken at the first place). I believe your investigation about newly set UID is correct, I also noticed that they do not match, but I thought it's not relevant, until you corrected my thoughts. 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
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] [evolution-kolab] On porting and extending the plugin
Hi Milan, Am Mittwoch 14 September 2011, um 08:25:20 schrieb Milan Crha: > On Tue, 2011-09-13 at 15:56 +0200, Christian Hilberg wrote: > > * IMAP ACL management. A new tab (or something alike) when > > right-clicking an IMAP folder in the Evo folder tree to view and > > edit IMAP access control lists as defined in RFC 4314 [4]. The IMAP > > ACL functionality will be implemented on a new branch based on A-B > > (see "Phase I, (1)"), much the same way ANNOTATEMORE has been > > implemented, to the extend needed for Kolab. This will lead to an > > API extension (like there already is in evolution-kolab-IMAPX). > > There will be the need to extend Evolution as well, as to make it > > use this API extension. It is currently not yet planned exactly how > > this can be done without littering Evolution with "the tacking on of > > arbitrary features" (MBarnes, [3]) > > (Kolab specific: no) > > Hi, > see how evolution-exchange provides the same functionality of Folder > Permissions, it just adds a popup menu item and servers all what is > needed without any special modification on evolution side. The same > should apply for the folder type annotation editing - no change on > evolution should be needed. I'll check that. The less change needed on Evo side the better. I'm not sure yet exactly how we will be able to solve it. I do not have knowledge about how folders are handled in Exchange, but for Kolab, it is IMAP - so we need the capability for IMAP ACL, which, unless I'm mistaken, IMAPX does not yet provide. This part will be done (for now) in our IMAPX derivative, and Evo will need to make use of this functionality one way or another. ACL management is not limited to the evolution-kolab backends and is needed for the Kolab email folders (which are plain IMAP folders) as well. Maybe we can do this in an EExtension, I'll check with evolution-exchange. If the UI extension evolution-exchange provides is fine for the Evo community (which I think it is), then we could try to mimick the layout in order to try for a consistent user experience. To that respect, maybe it will be possible to iron out some common approach for the groupware plugins that way, which I think is what Matt has in mind. > With respect of creating a new folder on the kolab server other than > mail: when you do File->New->Calendar and select the Kolab group, is it > able to create a new folder and annotate it accordingly to the source > group? Evolution-mapi provides a short folder list with folders of the > certain type from which user can choose and under this is created the > new calendar (or address book). Again, no change on evo side is needed > for this. As far as creating new PIM folders goes, this is correct. This can be done entirely in the backends, provided we can re-use existing account information (which in current Evo/E-D-S should be possible). Things are different when you need to change or set the type of an existing folder manually. This is for error recovery mainly, but has been described by our sponsor as a real life scenario which from time to time happens to occur (due to server failure or client error). To do this, it will be made possible to display the PIM folders in the email folder tree (though these folder's contents will not be accessible), so you can right-click the folder and edit the annotation it carries by selecting a type from a drop down list. This is the typical way Kolab clients will provide this functionality for the user. There are a number of issues related to this, e.g. the kolab backends need to be notified of the change do they can sort of "drop" a folder they are no longer supposed to care for ... whether or not we can sanely implement this remains to be seen. The goal behind this is to enable Evolution to act as a complete Kolab client, removing the need to resort to different clients to get all tasks done. Kind regards and thanks for the hints, 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] SyncEvolution + EClient API + EXDATE regression (Bug #655253)
On Mi, 2011-09-14 at 08:28 +0200, Milan Crha wrote: > yes, I agree, it wasn't the right change, I'm sorry for that. Please > revert the commit and reopen the bug. I reverted the EXDATE part of the commit, but couldn't reopen the bug (Bugzilla does't offer me that option). Can you reopen it? -- 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
