Hi List, I'm now working on the [0x3] phase: "Renaming MAPI structures".
I already have several improvements in the pipe, some of them already requiring changes in developer's applications. I initially had in mind to push a one-shot patch, so we can revert in case of problems, but this task changes a lot of code (impacting all parts of openchange) and it makes quite difficult to track down changes for a given modification. I'll push each change separately instead and send emails on the mailing-list explaining those which may/will impact external applications. This should make the upgrade process easier for external developers. Cheers, Julien. On Sat, 2008-09-06 at 22:18 +0200, Julien Kerihuel wrote: > Hi List, > > Quick update: "NSPI protocol update" and "Completing NSPI protocol > implementation in libmapi" tasks are done and committed on svn r726. > > This is an important update: most of the NSPI stack has been rewritten > and both the NSPI stack implementation and IDL are complete. There's an > exception regarding NspiModLinkAtt and NspiModProps which behavior isn't > - imho - clear in MS docs and for which I have asked further > information: > http://forums.msdn.microsoft.com/en-US/os_exchangeprotocols/thread/7beab30a-fa15-48f8-977a-4f951a933b7a > > I have also implemented a preliminary mapitest module for the NSPI stack > which I'll presumably improve and use to test the EMSABP server > robustness and behavopr. You can run the test suite with: > > $ mapitest --mapi-calls=NSPI-ALL --dump-data -d10 --color > > Developers using libmapi trunk shouldn't notice much difference except > if your application directly uses libmapi/nspi.c API. Developers relying > on IProfAdmin.c API are not affected by this change. > > However there is one difference that may affect your application: > the FlagList to SPropTagArray change. > You should normally only have to rename FlagList to SPropTagArray to > keep your existing application working. If it doesn't make the job, > please have a look at openchange tools and mapitest for implementation > examples. > > The next step will probably have more direct impact to your application > but is intended to make openchange MAPI structures closer to thoses > described in MS-* specifications. "[0x3] Renaming MAPI structures" > > FYI, the whole NSPI implementation was committed as one big chunk so we > can temporary revert in case something goes wrong. > > Cheers, > Julien. > > On Fri, 2008-09-05 at 15:54 +0200, Julien Kerihuel wrote: > > 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
