Hi Brad, I've merged back to trunk the makepropslist.py script (with all associated changes so it compiles properly).
First of all, I'd like to congrats you for this piece of code. It is
extremely valuable for MS-DOC sanity checks, moreover to keep openchange
consistent with regards to MS-OXPROPS.pdf.
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.
After a quick comparison with the mapi-named-properties file we
originally had in libmapi/conf/, the new version automatically adds 50
new properties. When required, we will be able to make further
amendments of the generated files under revision much quickly.
Given the performances of the parser and the fact that we've already
merged a good portion of mparse.pl work into makepropslist.py, I think
I'll continue the merging for named properties and generate the LDIF +
libmapi/named_* files which will be under revision instead of generating
mapi-nameid-properties and relying on mparse.pl for further processing.
Another aspect that comes with mapistore_v2 is the mapping of the
properties. Basically we have from 0x8000 to 0xFFFF to map properties
for a given user. Within this segment, some common named properties are
referenced by MS-OXPROPS and others are referenced by the MS-NSPI.
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).
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.
For the mapistore_v2 named properties database, 2 design are possible:
1. One global database with CN=username entries
2. One database per user
In both cases the mapping will be unique for each user. It is a "per
mailbox" mapping. My only concern is about performances:
1. In a global database, we only provision the database once
using a common set of properties. Any additional properties are
then appended and added to the CN=username entry such as
CN=0x8012,CN=username and won't ever overlap.
The concern is about LDB performances in read/write access.
Normally we should only have few write operations. This is a
one-time mapping for applications. So this may not be that
critical.
2. In a database per user scenario, if we have a lot of users,
we may have to open as many named props ldb files as we have
users. This doesn't sound to me like a sane design for long-term
development.
Cheers,
Julien.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
