On Wed, 2007-08-29 at 07:34 +0930, Dan Shearer wrote: > On Tue, Aug 28, 2007 at 11:47:28PM +0200, Julien Kerihuel wrote: > > On Wed, 2007-08-29 at 07:14 +0930, Dan Shearer wrote: > > > libmapi has global context by design. > > > > > > Are there situations, particularly in GUI groupware clients, where the > > > developer will want to open multiple sessions? > > > > Definitively and this situation also applies to console applications. > > Good, it's just that in the LCE paper we made apoint of how it was a > design goal to have global context. I suppose if you want to make it > impossible for people to do anything with threads then its great, but > apart from that I think it was only expediency.
Not at all. We we still need and use the global context. Moreover it has always been the objective to keep sessions info within global mapi_ctx and the structure is already defined so we can have multiple sessions. > There are dependency and ordering possibilities with Exchange objects > that I haven't got clear in my head but are certainly could get very > complicated. Not really. It's all about hierarchy, parents and children. Any object is created from another one except the initial store object (OpenMsgStore or OpenPublicFolder). > > You want to copy mail (CopyTo MAPI operation) from your Inbox (mailbox > > store) to a public folder one (PF store) when subject of emails matches > > a particular pattern. > > That's a kind of user-initiated pattern, and I'm sure that's valid. But > I was also thinking of things that happen automatically: async updates > of object status while you're assembling objects to create a mail for > example, so you have to the check the status of something else. > > > That is part of the improvement I want to bring prior releasing > > libmapi-0.6. I've identified how to do it, mostly keeping session > > context within each object rather than use global_context. Which implies > > removing the awful mapi_ctx->session->emsmdb->ctx. > > This could quickly chew up a lot of memory. I don't agree. We only need to keep a pointer on the associated session stored in the global context and shouldn't limit threaded application development. > Random guess: is there a way to optionally ask the server to perform > some operations for you and just inform by callback? MAPI lends itself > to batch operations in some ways, which means I could get a list of > operations and send it off to the server to process -- if the server > supported it. Some operation can send their results later if they have not finished. There is a special MAPI code for this IIRC, but this behavior doesn't apply to all MAPI calls. MAPI supports batched operations e.g: SetColumns+QueryRows or even more complex ones (can be up to 4-5 operations in some examples). IMO it is mostly implemented to reduce traffic and collapse operations related to the same handle. I don't think there is such callback mechanism, but some cases can be handled by the MAPI/UDP notification system which leads to similar behavior. (object modified etc.). I'll soon start to document and continue the notification implementation within libmapi. This may give up a more complete overview. -- 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
