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 GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.