Re: Is this really an LCUP show stopper?

Mark,

>LCUP does not require that the server be able to "recreate the previous 
>sync result." It requires that the server be able to, based on the 
>cookie supplied by the client, generate a set of Sync Update messages 
>that allow the client to synchronize with the server. This is a subtle 
>difference, but important in some scenarios.

No, LCUP doesn't. But an implementation needs to do for reasonablely
incremental synchronization.

>If a server implementor wants to minimize the Sync Update message sent 
>to clients and minimize the frequency of full resyncs and support all 
>possible sync scenarios, then yes, quite a bit of state information must 
>be maintained. But there are some tricks implementors can use to reduce 
>the amount of state storage needed. For example, in most environments 
>the search criteria used by all of the LCUP clients will involve a very 
>small subset of the attribute types and values contained in the DIT. If 
>my server only needs to support LCUP requests that use the search filter 
>(objectClass=person) then I can reduce the amount of "extra" state 
>storage down to a reasonably small amount. It will always be possible to 
>come up with examples that make LCUP look bad from one perspective or 
>another (wire traffic vs. server implementation burden), but I suspect 
>the same is true of most synchronization protocols.

Let me take the LDAP Proxy cache as an example. It's an important
application, even though it may just add another to the examples that 
make LCUP look bad. LDAP Proxy Cache caches LDAP results from LDAP servers
based on client queries. If a query is answerable from the proxy cache,
it returns LDAP result directly without contacting the server. If it's 
not,
it fetches results from the LDAP server and returns them to the client.
A client update protocol can be used to synchronize cached entries with
the server. Clients can request various search criteria to the LDAP Proxy 
Cache
which in turn will send LCUP requests with various search criteria to the 
server.
A good protocol needs be scalable and consider a wide range of the current
and also future applications.

- Jong

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
email: [email protected]
(phone) 914-945-3979    (fax) 914-945-4425   TL: 862-3979