Re: Comments on ldup-replica-req-00.txt

["John Merrells" <merrells@xxxxxxxxxxxx>]

Alan Lloyd wrote:

> > I'm not sure how you managed to derive this from the text.  I see
> > nomention of a client maintaining replica consistency between
> > two servers.
>         Perhaps it was that LDAP - as a client-server ACCESS protocol
> that swayed me. Is LDAP now a LDRP or something (replication) and server
> to server operations.

Servers can behave as clients to each other.

>         Does this mean changes to the LDAP RFC?

Probably, in the form of new controls, and possibly extended operations.

>         You see replication needs to be initated by either server and
> replicas transferred in either direction so its either a bi-directional
> LDAP server to server with transaction control and server based
> management and a lot of Gods help (this is not a religious statement
> ;-))

It could be a session in each direction.

>         OR its a third party client application controlling the
> replication via LDAP.

I doubt anyone would want to implement that... unless it had someother synchronization functionality.

>         I dont care  which - the transaction/atomicity problems are the
> same. And the updates to the LDAP RFC may be needed.

I should think that new controls will suffice.

>         Its seems that LDAP is getting more onerous with its DIT locking
> and transactions and exposing this into the protocol. Is it likely that
> X.500 DAP and DISP will be less protocol than LDAP and do more - more
> effectively?

Depends what the LDAP replication architectural proposals are like.

>         But then how will I get the master entry if I need it. I may be
> connected to a replica server for my address book details, but would
> really like the military target information from the master in case its
> been updated in the last ten minutes and has not been propagated yet.
>         Users must have the mechansims to get to master info - in case
> of inconsistencies caused by latent replica updates -
>         See X.500 - Dont Use Copy, Copy Shall Do, its defined, it works
> and its useful.

So far, no one's suggested this as a requirement.

I'd wonder though... that if your application has real-time constraints then
you probably don't want to store your data in some loosly consistent store.

Also... if an entry is mastered by many servers... then you won't know
which server holds the 'correct' value anyway.  So it doesn't sound like
this buys you much.

>         How do we manage these tags (in attributes?) across tens of
> replicas if not hundreds -

I'm worried that attribute value tagging might limit scalability, but amexploring a change log approach to see if a server can
be limited to
only knowing about the state of it's peer, rather than the entire
directory server topology.

How does X.500 deal with this?

>         Oh really - how does the server know its a partial entry or not.

The replication agreements define the area of the tree to be replicated,including an entry and attribute filter.

>         See X.500 Copy shall do...

Eh?

John

--
John Merrells
Netscape Communications
Directory Server
Software Engineer

http://people.netscape.com/merrells