Re: LCUP and PSearch on Sync-And-Persist

There are many clients which need to know they are 'in sync'.
I note that this is not just after the initial 'sync up' phase,
but subsequently.  Also, there are cases where the server
needs to update the cookie without sending an update (in the
'persist' phase.

I suggest that we add a 'in sync' notification to LCUP.  Basically,
just a (intermediate) response PDU which says "you're in sync"
and, OPTIONALLY, provides a new cookie.

The server should send one when it has sent all changes necessary
to 'sync' the client.  The server may send them subsequently to
again notify the client it is 'in sync'.

Kurt

At 08:16 AM 2002-04-04, Rich Megginson wrote:
>Mark C Smith wrote:
>
>> Timothy Hahn wrote:
>>  >
>> > What about a client that wants to "hold off" on handling search requests
>> > until it knows that its
>> > information is "close" to what is held in the server?  "close" being
>> > defined as the "synchronization"
>> > part being done and only "updates" will be sent from here forward.
>>
>> I think this may be a valid requirement for LCUP. With Persistent
>> Search, a client can tell where the stream of changes begins, but only
>> after the first change is received (by looking for the presence of an
>> entryChangeControl in the SearchResultEntry PDU).
>
>Do we need to have the sync phase be completely finished before the persistent phase begins?  Or is it merely enough to know that
>a returned entry is from the sync phase or the persistent phase?  For the latter, it would be easy to add another field to the
>response control.  For the former, that would be much harder for server implementors to guarantee some sort of order I think.
>What is the requirement?
>
>>
>>
>> -Mark Smith
>>   Netscape