Hi Krishna, It's nice to hear back from you.
On Wed, 2010-01-06 at 09:24 -0800, Krishna Ganugapati wrote: > Hello Julien and Openchange folks > > Over the last couple of weekends, I've been experimenting with the > openchange emsmdb.idl file and seeing if it could be adapted to be > used by the dcerpc compiler. I've noticed this particular anomaly in > the mapi_requst structure. > > The last field in the mapi_request is a pointer to a handle array - > int *handles. This is usually variable length - some calls take two > handles and some take just one handle. In dce/rpc, this would need to > be specified apriori with an attribute size_is(count) - where some > previous variable provides the number of handles to marshall. > > But the specification has no such field. So I hardcoded it to always > accept 2 handles. Actually the handles array can be more than 2 handles (and is generally the case). The IDL just describes a convenient packing structure we next marshall/unmarshall manually in ndr_mapi.c. To make it simple: 1. We have the EcDoRpc packet with a 4 prefixing bytes (the subcontext) specifying the overall size of the mapi_request (or response - depending on IO) structure. 2. The mapi_request structure is made of a non-aligned array of EcDoRpc_MAPI_REQ (or EcDoRpc_MAPI_REPL if we discuss responses) - just dumped one after the other - each entry representing a MAPI call with its specific size (variable). 3. Finally we have the handles array which offset is length + sizeof(mapi_length) and which size is mapi_length - length. The array of handles is varying and given there is no NDR encoding there, we have no prefixing field we can use to standardize this part of the IDL. I think the schema available on slide 29/36 in http://www.openchange.org/images/openchange/conferences/download/openchange_courses_001_understanding_mapi.pdf should make things more understandable. > > Also, I was curious to know if there is any interest in reconciling > these changes. pidl has very different syntax than standard dce/rpc > idl... If there is any way to conceal both implementation within the same IDL, I'd be happy to merge it into trunk. > > Glad for any clarification here? Sure, please proceed. I think this is a very worthwhile discussion that can probably lead into interesting results. 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
