Hey, Thanks a lot for your answers. We'll start looking into things and get back to you when we have some findings or questions.
With my best regards, Christian On Thursday 04 October 2012 16.40:35 Julien Kerihuel wrote: > > 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_Developm > ent_Guide > > > Kind Regards, > Julien.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
