Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders
On Tue, 2010-07-20 at 13:18 +0200, Christian Hilberg wrote: > Hm. Maybe I'm still missing some parts here on how Evolution > internally works. > > Subclassing the Camel Provider in our backends and overloading > get_folder_info() will work for the backend part, i.e. PIM data wich > is accessed and managed from inside E-D-S. So far, no problem. > But there is standard Email to handle as well, and if I understood > correctly, Email handling is (presently) done inside Evolution, not > E-D-S. Hi, others will correct me, but from evolution-mapi point of view (which is, with evolution-exchange, closest to that what you are trying to do): - create a Camel provider, which, when placed to the right place, will be shown in new account creation as an account type (see camel-mapi-provider.c, there's everything needed for having new mail provider available in Evolution). Evolution-mapi is extending basic camel objects, like CamelStore, but as you want to use IMAPX, then less work for you, derive from it. Note that this Camel part has nothing to do with EPlugin, the most you define an EPlugin to add menu options on your folders, like "Folder Size" option for MAPI folders, but other than that the EPlugin part is optional for mailer part. - for calendar and addressbook support create your own EBookBackend/ECalBackend descendants (with defined all the virtual methods there). You need an EPlugin to have them accessible from UI, to be able to setup specific things on it. See exchange-mapi-account-setup.c:exchange_mapi_create_addressbook and exchange_mapi_create_calendar as examples. Note these are mentioned in org-gnome-exchange-mapi.eplug.xml. - evolution-mapi's EPlugin also listens for changes on EAccountList (which is a list of configured mail accounts) and adds/removes ESource-s for addressbooks/calendars based on enabled/disabled MAPI accounts, keeping these three in sync, so the only thing user needs to setup is an email account, and the addressbook/calendar are added automatically. With respect of folder structure changes, the first sync will update internal caches as necessary, namely camel-store-summary, allowing you to hold the necessary information about each folder, and also adding the type annotation on it too. How or when fetch that annotation is a question for you. 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] evolution-kolab: hiding IMAP folders
Hi there, On Tuesday 20 July 2010 chen wrote: > On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: > [...] > > Is it possible to define certain IMAP folders as "hidden" from within > > our plugin's EPlugin part? Or is it possible to hide certain IMAP > > folders (and their subfolders) in any other sensible way? > > This cannot be done in a fool-proof way for IMAP as it does not provide > information on the type of the folder. This can be done with an > assumption that calendar folder will be named as 'calendar' or contact > folders as 'contacts'. Not entirely correct, though. "RFC 5464 - The IMAP METADATA Extension / imap- annotatemore" specifies an extension to the IMAP protocol which does exactly that. The Kolab IMAP daemon uses this extension to differentiate between the folder types and Kontact does implement it - works quite well. Now, with our plugin, we strive to be en par with Kontact's features (or at least implement as much as possible) - let's see! :-) > The other thought I get is, the contacts+calendar folder names can be > collected as an option in account-setup and set as part of camel url > (prolly through a kolab plugin, hiding it from the user. you can check > how groupwise account set-up is implemented for an example) say > hide_folders="list of folders with a separator". If the parameter is > set, the folders can be hidden while fetching folder_info through > camel_store_get_folder_info (in imapx backend), which gives the folder > tree. Good idea. We'll have to check how to handle dynamic changes in the IMAP folder structure, still. Folders with annotations may come and go, nested or not - this is not static, and neither is the overall layout (other than a few static constraints), so we'll need to see how we can cope with that... > We could add another flag in CamelStore to over-ride the above option to > fetch all folders while fetching the folders from > contacts(EBookBackend)/calendar(ECalBackend) backends. > I can help you with making these changes in imapx backend/CamelStore and > inform you the changes which you would need to make in your > account-setup plugin. Sounds ok? We'll thankfully use whatever help we can get here. We also see clearly which problems arise in these areas because of our decision to settle on 2.30 ... this is the version we would need to change (branch is fine). It will be very much helpful to know which parts will be affected and how we should design our changes in order not to break anything. Thanks again for your help and for your awesome patience with us (this goes to the entire list). Best regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 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: hiding IMAP folders
Hi there, thanks Milan for your reply. On Tuesday 20 Juli 2010 Milan Crha wrote: > On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: > > Is it possible to define certain IMAP folders as "hidden" from within > > our plugin's EPlugin part? Or is it possible to hide certain IMAP > > folders (and their subfolders) in any other sensible way? > > Hi, > you said you want to use imapx internally, is it right? And even if IMAPX-only, yes. That's the master plan. :-) > "only" the imap provider itself, then I would suggest to subclass it > (your base imap provider) in your evolution-kolab "package" and manage > this within CamelStore::get_folder_info, by calling parent class' > get_folder_info and then recreate folder information based on your needs > (once with email folders only, once with calendar folders only, and so > on). Hm. Maybe I'm still missing some parts here on how Evolution internally works. Subclassing the Camel Provider in our backends and overloading get_folder_info() will work for the backend part, i.e. PIM data wich is accessed and managed from inside E-D-S. So far, no problem. But there is standard Email to handle as well, and if I understood correctly, Email handling is (presently) done inside Evolution, not E-D-S. Now, if I create a Kolab account, I will see not only the Email IMAP folders in Evolution (frontend, Email view), but *also* the parts of the IMAP tree for the Kolab server which hold PIM data. These are simply IMAP folders, just that they bear folder annotations. Other than that, the folders which hold PIM data (as single emails with XML attachments) are no different from true Email folders. This means, when I configure Evolution (2.30 let's say, without any Kolab plugin) as to access a Kolab server, nothing hinders Evolution to display the whole IMAP tree and the folders which hold PIM data just become visible as standard Email folders. This I cannot intercept from my backend code (or can I?), since Evolution just accesses the Kolab IMAP server without knowing that certain IMAP folders do not hold standard Emails which must not be accessible to the user. What's more, the IMAP folder layout in Kolab may change over time, as I create new address books, nesting things etc, so the folder tree is not static. Therefore, I cannot just pre-configure which folders to show and which ones to hide, I'll have to do this dynamically, solely relying on the folder annotations telling me which kind of IMAP folder I'm facing. For this to work, I would have to subclass the Camel Provider within my EPlugin - is that possible? So far, I have only seen EPlugins using existing Evolution infrastructure, but not changing the Camel Provider inside Evo... > Hope that helps, Partly, yes. :-) Please feel free to correct me on any misconception I have regarding the internals of Evo/E-D-S, I'll be grateful for that. Also, if I need to be clearer on any Kolab issue, please let me know as well. > Milan Best regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 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: hiding IMAP folders
On Tue, 2010-07-20 at 12:41 +0200, Milan Crha wrote: > On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: > > Is it possible to define certain IMAP folders as "hidden" from within our > > plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and > > their subfolders) in any other sensible way? > > Hi, > you said you want to use imapx internally, is it right? And even if > "only" the imap provider itself, then I would suggest to subclass it > (your base imap provider) in your evolution-kolab "package" and manage > this within CamelStore::get_folder_info, by calling parent class' > get_folder_info and then recreate folder information based on your needs > (once with email folders only, once with calendar folders only, and so > on). Just noticed the reply. I dont think it requires sub-classing as it seems to be applying for other collaborative backends such as groupwise where we would need to hide some folders iirc it was tasks/contacts (sorry forgot the exact folders), but remember discussing with Akhil. - Chenthill. > Hope that helps, > 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 ___ 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: hiding IMAP folders
On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: > Hi all, > > ...still continuing... > > Kolab makes use of "RFC5464 - The IMAP METADATA Extension" IMAP folder > annotations to differentiate between the various folder types which are > handled by Kolab. Remember, anything (Email and PIM data) is stored as Email > messages with XML attachments in IMAP folders within the Kolab context. This > means, we have IMAP folders for Email, Calendars, Contacts, TODOs, Tasks and > the like. > Now, when creating a Kolab account, all of these folder types are generated > on the server. There is at least one folder for each type, which is the > default folder initially. > From within Evolution, *only* the IMAP folder which is annotated "Email" > should be visible and all others should be hidden, as their respective > contents will be managed by the backends, not Evolution. Otherwise, users > will > be able to meddle with PIM data folders, which might result in disastrous > situations on the server side. > Is it possible to define certain IMAP folders as "hidden" from within our > plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and > their subfolders) in any other sensible way? This cannot be done in a fool-proof way for IMAP as it does not provide information on the type of the folder. This can be done with an assumption that calendar folder will be named as 'calendar' or contact folders as 'contacts'. The other thought I get is, the contacts+calendar folder names can be collected as an option in account-setup and set as part of camel url (prolly through a kolab plugin, hiding it from the user. you can check how groupwise account set-up is implemented for an example) say hide_folders="list of folders with a separator". If the parameter is set, the folders can be hidden while fetching folder_info through camel_store_get_folder_info (in imapx backend), which gives the folder tree. We could add another flag in CamelStore to over-ride the above option to fetch all folders while fetching the folders from contacts(EBookBackend)/calendar(ECalBackend) backends. I can help you with making these changes in imapx backend/CamelStore and inform you the changes which you would need to make in your account-setup plugin. Sounds ok? - Chenthill. > > Many greetings, > > Christian > > ___ > 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] evolution-kolab: hiding IMAP folders
On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: > Is it possible to define certain IMAP folders as "hidden" from within our > plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and > their subfolders) in any other sensible way? Hi, you said you want to use imapx internally, is it right? And even if "only" the imap provider itself, then I would suggest to subclass it (your base imap provider) in your evolution-kolab "package" and manage this within CamelStore::get_folder_info, by calling parent class' get_folder_info and then recreate folder information based on your needs (once with email folders only, once with calendar folders only, and so on). Hope that helps, 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] evolution-kolab: hiding IMAP folders
On tuesday 20 July 2010 Christian Hilberg wrote: > [...] > From within Evolution, *only* the IMAP folder which is annotated "Email" ^^ "the IMAP folders which are annotated", this is. Best regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 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
[Evolution-hackers] evolution-kolab: hiding IMAP folders
Hi all, ...still continuing... Kolab makes use of "RFC5464 - The IMAP METADATA Extension" IMAP folder annotations to differentiate between the various folder types which are handled by Kolab. Remember, anything (Email and PIM data) is stored as Email messages with XML attachments in IMAP folders within the Kolab context. This means, we have IMAP folders for Email, Calendars, Contacts, TODOs, Tasks and the like. Now, when creating a Kolab account, all of these folder types are generated on the server. There is at least one folder for each type, which is the default folder initially. From within Evolution, *only* the IMAP folder which is annotated "Email" should be visible and all others should be hidden, as their respective contents will be managed by the backends, not Evolution. Otherwise, users will be able to meddle with PIM data folders, which might result in disastrous situations on the server side. Is it possible to define certain IMAP folders as "hidden" from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and their subfolders) in any other sensible way? Many greetings, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 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
