Hi List, Here is a status update of the work in progress and a more detailed roadmap of the NSPI development part.
[0x0] Contents
==============================================================
[0x1] NSPI protocol update
[0x2] Completing NSPI protocol implementation in libmapi
[0x3] Renaming MAPI structures
[0x4] Create the nspi_server mapiproxy module
[0x5] EMSABP provider merging
[0x6] EMSABP provider update
[0x7] RFR and NSPI wireshark dissector
==============================================================
[0x1] NSPI protocol update
==========================
I've started to work on a complete update of the NSPI protocol, closely
following MS-NSPI.pdf specifications. This task is mostly about renaming
IDL function and fields, add new set of structures and modify existing
ones to match the IDL with more accuracy. This preliminary task is
almost over:
- NSPI profiles work properly again
- existing EMSABP provider, dcesrv_exchange and mapiproxy have
been updated to reflect these changes. There is still a bit of
inconsistencies in dcesrv_exchange, but this file is scheduled
for deletion and will be replaced in further commits by a brand
new and working mapiproxy module.
I'll however be waiting for [0x2] to be completed before I push the
first update.
Note that this task shouldn't normally affect external applications if
you rely on the IProfAdmin interface. If you directly call API functions
from libmapi/nspi.c, then you'll have a bit of renaming to do in the
future.
[0x2] Completing NSPI protocol implementation in libmapi
========================================================
I've also started this task and have begun to implement some new NSPI
function (IDL + libmapi implementation) such as NspiQueryColumns or
NspiSeekEntries. I have also started to write a new mapitest module
designed to test the NSPI protocol functions. This task will be
completed when the full protocol is implemented, NSPI mapitest module is
complete and pass the full NSPI tests.
When this task is over, (scheduled for the end of week), I'll push the
first update on trunk.
[0x3] Renaming MAPI structures
==============================
Ticket #002 on http://trac.openchange.org is inconsistent regarding the
scope of the planned update and will be updated to reflect the intended
modifications. Basically, this modification is about making libmapi data
structures naming more conventional and remove the mapi_ prefix to MAPI
structures in the EMSMDB IDL. NSPI structures will be suffixed with _r
as specified in the specs.
This may require a major update for developers using openchange, but
this will be a one shot effort. Furthermore, some of the structures
names won't be changed as it would be more inconvenient than worthwhile.
[0x4] Create the nspi_server mapiproxy module
=============================================
I have already implemented a preliminary skeleton of the nspi_server
mapiproxy module designed to dispatch NSPI calls to the correct
function. I'm also in the process of merging server/dcesrv_exchange.c
NSPI related code into this module and brings the necessary updates:
sanity checks etc.
One of the task (which shouldn't be too long), will be to add some
parametric options to smb.conf and let the user choose whether it wants
mapiproxy to act as a real Address Book provider (nspi_server mode) or
transparently relay the traffic. FYI, there is already a
dcesrv_mapiproxy_nspi.c file into mapiproxy designed to modify some NSPI
traffic on the fly. mapiproxy needs to use either this file in case it
relays the traffic or the forthcoming nspi_server is it acts as a
server.
[0x5] EMSABP provider merging
=============================
The next step is to merge the existing EMSABP provider into mapiproxy.
I've also started to work on this task and I am rewriting the provider
from scratch so it includes more sanity checks and gets closer to
MS-NSPI specifications (expected server behavior). This task also
includes the merge of provisioning scripts back to trunk, so we can
extend Samba4 AD schemas, attributes and users entries with Exchange
ones again. I am yet unsure how long this merge/update process will
require.
[0x6] EMSABP provider update
============================
The next step is to improve the EMSABP provider so it can handle a more
consequent set of NSPI calls. This will probably lead in an update of
the EMSABP provider, Exchange schemas, attributes and MAPITAGS to x500
mapping table.
[0x7] RFR and NSPI wireshark dissector
======================================
Last but not least, I thought you might be interested to know I have
supplied a patch to wireshark to add RFR protocol dissector and will
send an update for the NSPI dissector as soon as task [0x2] is over.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2850
That's all for the moment.
Cheers,
Julien.
On Wed, 2008-09-03 at 17:04 +0200, Julien Kerihuel wrote:
> 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.
>
> _______________________________________________
> devel mailing list
> [email protected]
> http://mailman.openchange.org/listinfo/devel
--
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
