[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: direct local change when a consumer chains a write to the producer?
- To: ando@sys-net.it
- Subject: Re: direct local change when a consumer chains a write to the producer?
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Wed, 07 Dec 2005 13:42:40 +0100
- Cc: "Howard Chu" <hyc@symas.com>, "OpenLDAP devel list" <openldap-devel@OpenLDAP.org>
- In-reply-to: <40013.131.175.154.56.1133775437.squirrel@131.175.154.56>
- References: <313423751.20051110113255@uaic.net> <42138.192.168.1.254.1132334767.squirrel@tomate.linagora.lan> <48887.10.0.14.46.1132341797.squirrel@mail.ivytech.edu> <465451149.20051118224611@uaic.net> <20498EEB4C91E6CD7543390E@cadabra-dsl.stanford.edu> <1466010362.20051119122217@uaic.net> <0F84CCF877D1F094219160DC@cadabra-dsl.stanford.edu> <1132493739.3316.112.camel@ando> <F5A02675FC28DA7864C3438C@cadabra-dsl.stanford.edu> <1132505214.3316.117.camel@ando> <43528.192.168.1.254.1132565037.squirrel@tomate.linagora.lan> <32823.10.0.14.46.1132587321.squirrel@mail.ivytech.edu> <53801.192.168.1.254.1132588966.squirrel@tomate.linagora.lan> <1132590414.3330.4.camel@ando> <33022.10.0.14.46.1132590508.squirrel@mail.ivytech.edu> <54934.192.168.1.254.1132591085.squirrel@tomate.linagora.lan> <1132592221.3330.14.camel@ando> <1132594689.6044.6.camel@ando> <6.2.1.2.0.20051121110557.03272008@mail.openldap.org> <1133163684.3318.10.camel@ando> <438AC745.7030709@symas.com> <6.2.1.2.0.20051128051020.02a88fa8@mail.openldap.org> <39326.131.175.154.56.1133193844.squirrel@131.175.154.56> <39351.131.175.154.56.1133195123.squirrel@131.175.154.56> <6.2.1.2.0.20051202123838.02f1f960@mail.openldap.org> <40013.131.175.154.56.1133775437.squirrel@131.175.154.56>
At 10:37 AM 12/5/2005, Pierangelo Masarati wrote:
>Agree; but I fear the issue here is to workaround the behavior of clients
>that shouldn't even be aware of contacting a replica
Upon successful completion of an LDAPv3 modify operation,
I believe it reasonable for the client to assume it is
communicating with the master in reading back the
modified entry with a search. (However, it would be
inappropriate for the client to assume other changes
did not occur between its modify and its search.)
Anyways, my point here is that it is reasonable
expectation that for any intermediary which
forwards a modify request to also forward
subsequent search requests.
While we can hope future clients will use various
LDAP extensions, such as readentry controls, we
obviously cannot expect any client to actually do so.
Kurt