Hi List, You will find below information about the roadmap on openchange server, how we plan to update the existing code and preliminary information on the EMSMDB store development roadmap.
[0x0] Contents
=======================================================
[0x1] Introduction
[0x2] Hybrid design: merging server and mapiproxy
[0x3] Next step
[0x4] References
=======================================================
[0x1] Introduction
===================
OpenChange has in the past implemented half an Exchange server (EMSABP
provider - AddressBook), but due to the efforts on libmapi, work on the
EMSMDB provider - the core of openchange server - has critically been
slowed down. Furthermore the EMSABP is at the moment outdated and not
usable in trunk.
In the meantime, we have put a lot of design, development and
documentation efforts in mapiproxy [1]. This hybrid proxy server starts
to have nice features such as the cache module which is able to replace
a real Exchange server for some operations such as attachments or large
message contents streaming. It also offers read-ahead and norelay
options so mapiproxy modules can really control how they discuss both
with MAPI clients and remote Exchange server.
Last but not least, there is an issue between openchange server and
mapiproxy. Both of them registers the same endpoints and you can't have
both shared libraries installed at the same time.
[0x2] Hybrid design: merging server and mapiproxy
==================================================
The new approach will be to merge openchange server into mapiproxy.
The main objectives are to fix the incompatibility mentioned above, put
openchange server on good rails again and finally improve mapiproxy with
important features.
This will let users configure mapiproxy to act as a transparent gateway
and/or progressively and seamlessly replace an Exchange server with
openchange.
Some of the forthcoming modules we can plan is to progressively populate
Samba4 AD when data is not available in the SAM database. For example:
1. Outlook wants to resolve a name (NSPI - EMSABP provider)
2. mapiproxy asks openchange server for the name
3. If openchange server has the information, it is returned
directly to Outlook
4. If openchange server doesn't have the information, mapiproxy
relays the information to the real Exchange server, update the
SAM database with the information fetched and return the info
back to the client.
5. When Outlook requests for the same username again, it is read
from openchange server and requests are not forwarded to
Exchange anymore.
For this integration to be successful, Jelmer's work on python's
provisioning script will be merged back to trunk, providers be moved
into mapiproxy and a new module will be developed to call emsabp
provider. I'm willing to finish the initial merging task within the next
2 weeks. The update module designed above will next be developed
depending on expressed needs.
I also plan to start the development of a exchange_ds_rfr provider and
mapiproxy module. Finally I plan to implement a skeleton draft of a
emsmdb provider.
[0x3] Next Step
================
When the work above above is completed, I'm willing to schedule a
meeting with people interested in mapidb development (as described in
[2]) and define a preliminary functional draft and API for the
abstraction storage backend.
[0x4] References
=================
[1] http://mapiproxy.openchange.org
[2] http://wiki.openchange.org/index.php/EMSMDB
Cheers,
Julien.
--
Julien Kerihuel
[EMAIL PROTECTED]
OpenChange Project Manager
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
