Pierre-Arnaud Marcelot wrote:
I'd love to do option #2 but this is something we can not do as the
project I'm working on should not have any impact on the underlying
applications except the application which exposes the model and
discusses with the storage.
I can't do option #1 as it the aim of the project... ;)
I think we'll _just_ need to integrate the handling of the incremented
IDs in the application we're re-writing (searching for the next
available id and then insert the entry once we've figured out what
value to use).
The idea is also to keep the existing API for compatibility reasons,
but deprecate a few elements in the model and additionally provide a
*cleaner* API that applications could use for a future migration.
This is a form of #2 (make the client not require the LDAP server to
implement small positive integer unique ID generation).
It won't work in a replicated environment, (a variant of the scheme
where you build a your own distributed id allocation service would fix
this), but you may not have that requirement.
