> We're currently in the process of evaluating how to provide MAPI access to > the > Kolab Groupware Server [0] through OpenChange. > > Since Kolab stores all it's groupware objects (events, notes, etc.) wrapped > in > MIME messages inside the IMAP store, we essentially want to write a backend > which converts to/from our format and accesses our server via IMAP. > > From what we have seen so far it seems like libmapistore is what we're > looking > for. We have found the FSOCPF backend in older svn revisions, which looked > like a nice starting point, however, it seems all the backends vanished in > current master.
Hi Christian, You are correct, the fsocpf backend got removed from trunk - for now at least - because of some semantic changes introduced in mapistore design along with some code changes. Theses changes impacted the core functions of fsocpf and required a complete rewrite, which was a bit tricky due to the several and regular API changes (till now). For example the cached mode or ACLs which are handled by IMAP server through SOGo backend (e.g. QRESYNC and ACL plugins for dovecot). FSOCPF backend on its own lacks these features which are required to work with Outlook in cached mode (enabled by default). I suspect that Kolab may benefit from IMAP features in the way SOGo backend does but maybe move from SOGo line when it comes to message handling and MIME message. This obviously require some more discussion but that could be a possible option. > It would be great if you could give use some pointers if we're digging in the > right direction and what you think would be a good starting point (something > like the FSOCPF filesystem backend would be nice). Also, should work with > master or what version would you recommend? In the first place, I would recommend to test the sogo branch and I'll keep you posted when trunk is sync'd with this branch again - probably around next week. I guess you want to try an almost production ready backend first so you can evaluate the different implemented features. Then consider if you want to cope with the existing approach or need some updates that may diverge from sogo branch needs. > Also I couldn't quite figure out what is available to write tests, as that is > in any case going to be somewhat difficult with the servers in the process. We have a tool called mapitest, available in utils/mapitest and which let you write scenarios or test individual MAPI functions. It has been designed to test and stress servers, so it may be a good starting point for QA. We also have command line clients such as openchangeclient or mapiprofile which may be useful to test common use scenario such as sending an email with attachments or creating/modifying/deleting contacts, appointment, notes etc. > Is our best bet to write a simple testclient which manipulates objects in the > server and check the result in out imap backend, or are there other options > available? We probably need to discuss this a bit more to evaluate if our current test infrastructure is enough for your needs. > As first steps we're planning on setting up an OpenChange server with some > backend which we can then hopefully manipulate as starting point. > > Hope that makes sense =) Absolutely ;-) Let me also point you to some additional documentation - which may require a bit of update but which should be accurate for most of it: http://tracker.openchange.org/projects/openchange/wiki/MAPIStore_10_Development_Guide Kind Regards, Julien. -- Julien Kerihuel [email protected] OpenChange Project Founder GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
