On Mon, 2009-03-02 at 13:39 +0100, Miklos Balazs wrote:
> Dear Julien!
> 
> Thank you for the answer, it made a lot of things clear to me. So now
> I think the best way to accomplish what I want would be to write a
> backend to the mapistore layer, and write a custom EMSABP provider for
> the address book (as, as far as I can tell, your EMSABP implementation
> lacks a middle abstraction layer like the mapistore in your EMSMDB
> implementation).

Hi Miklos,

Indeed the EMSABP provider was not designed to include a middle
abstraction layer. NSPI/EMSABP is roughly just a wrapper/proxy over
Active Directory: turning AD information into MAPI data structures and
translating search request/replies (It is just like a 1-1 mapping
between AD attributes and MAPI property tags)

I am not sure writing a custom EMSABP provider would be the best
solution, maybe working on making sure NSPI/EMSABP can properly fetch
information from a LDAP backend would give you the flexibility you're
looking for. Mixing LDAP schemas within a heterogeneous environment
Samba with LDAP backend + 3rd party groupware with LDAP auth scheme +
whatever other services look to me like a more reasonable way to
proceed.

> I've looked at the mapiproxy code a bit, and saw that the
> emsmdb/mapistore code currently available in the repo consists mostly
> of initialization related stuff. Since I don't have an insight on how
> much work needs to be done implementing these providers, could you
> please give me a rough estimate on when can I expect that your EMSMDB
> implementation will have enough features, and a stable API, so that I
> can start implemening my own mapistore backend? I don't need an exact
> date, I just would like to know that it'll be in 1-2 months or more
> like 5-6 months?

A stable/frozen API is IMHO - at least - 5-6 months far from here.
However preliminary working version including some of the semantics
required to read/write messages, get contents table etc should probably
be available within 2 or 3 weeks, maybe less, maybe more.

It is intended to be working for POC-1.

Now openchange server lets Outlook opens properly, it make testing a lot
more easier (both with openchangeclient and Outlook).

Cheers,
Julien.

-- 
Julien Kerihuel
[email protected]
OpenChange Project Manager

GPG Fingerprint: 0B55 783D A781 6329 108A  B609 7EF6 FE11 A35F 1F79

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
devel mailing list
[email protected]
http://mailman.openchange.org/listinfo/devel

Reply via email to