On Wednesday, February 02, 2011 03:13:41 am Julien Kerihuel wrote: > I have added a small fix to the script (r2599) which fixes Property > Names parsing for named properties. We had cases with urn:, DAV: or > http: and the split was incorrectly splitting sub part of the property > name. Thanks. Named properties wasn't really "done" in my version.
> The last point is about the server's specific propID OpenChange server > will be using for a given property. So far we were relying on a table > extracted from a running Exchange 2003 server. I think such constraint > is now useless. We should start the server mapping at 0x8000 and > increment (minor the NSPI properties that hit the 0x8000-0xFFFF range). Possibly we need to map these into some kind of separate namespace. > In the end, we should potentially be able to have a consecutive range of > properties and one single index to maintain (per user) rather than a > pool of available IDs. I'm not sure how "safe" it would be, but it might be possible to recover property ids that aren't being used any more (e.g. were allocated, used only one message, then the message was deleted). We'd need to run this when the user wasn't logged in. In any case, I remember a blog post that stated Exchange doesn't do this. > For the mapistore_v2 named properties database, 2 design are possible: > > 1. One global database with CN=username entries > 2. One database per user I note your concerns, and don't know how to choose between these options. The locking contention could get quite bad in the first case, and the number of open ldb databases could be more than the number of logged in users in the second case (e.g. for "open other users folder"). [I think the second option should be "per store" (e.g. archive is a separate mailbox, with separate logon), rather than per-user, but I don't think that really changes the design considerations here.] I can only suggest another abstraction layer so we can switch if we guessed wrong. Brad _______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
