Re: LCUP and PSearch on Sync-And-Persist

Rich,

Two comments below - with <TJH> ... </TJH>

Regards,
Tim Hahn

Internet: [email protected]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681



                                                                                                                                       
                      [email protected]                                                                                                
                      m (Rich                  To:       [email protected]                                                            
                      Megginson)               cc:       [email protected]                                                             
                      Sent by:                 Subject:  Re: LCUP and PSearch on Sync-And-Persist                                      
                      owner-ietf-ldup@m                                                                                                
                      ail.imc.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      04/03/2002 09:34                                                                                                 
                      PM                                                                                                               
                                                                                                                                       
                                                                                                                                       




>                       Mircea Pana
>                       <[email protected]        To:       IETF LDUP
<[email protected]>
>                       om>                      cc:
>                       Sent by:                 Subject:  LCUP and PSearch
on Sync-And-Persist
>                       owner-ietf-ldup@m
>                       ail.imc.org
>
>
>                       03/26/2002 10:25
>                       AM
>                       Please respond to
>                       mpana
>
>
>
> Both LCUP and PSearch are unclear on the order of results sent back to a
> client in case of a sync-and-persist search request. An order seems to
> be suggested but not formally recommended.
>
> If a client issues a search requests with the appropriate control and
> specifies updateType=synchronizeAndPersist (LCUP) or changesOnly=FALSE
> (PSearch), in response the server will start by sending all the data
> needed to synchronize the client. If a change occurs to an entry which
> satisfy the search criteria while the server is still synchronizing the
> client then:
> 1. the server will pause the synchronization, sent that changed entry to
> the client and then resume the synchronization
> -or-
> 2 (suggested). the server will queue the changed entry and sent it to
> the client after the synchronization is completed
> -or-
> 3. the server will ignore the change
>
> Which one of the above is recommended by LCUP / PSearch?

I'm speaking only for LCUP, not PSearch.
I think the above assumes that entries sent during the synchronize phase
are somehow different from the entries sent during the
persistent phase.  Why should the client care if either 1 or 2 is used?
For 1), why would the server have to pause?  It could
just insert the changed entry either into it's outgoing sync queue, or it
could put it on the end of the queue.  I don't think it
matters as long as the implementor has designed the server such that the
server knows exactly where it left off if the connection
is cut.  The cookie sent back to the client should contain all the
information required to resync that client, hopefully with no
overlaps.
<TJH>
I suspect there exists a "time window" where the client may not have enough
information
(yet) in order to do anything "meaningful" with the "changed entry",
depending
on where the server "inserted the changed entry" into the outgoing sync
queue,
based on what has been sent to the client so far.  This implies to me that
the
server has to be "somewhat intelligent" in when it can finally send
"changed entries"
to the client.
</TJH>

> How is a client informed that the synchronization is complete and the
> only results that it may eventually receive are changes?

I'm not sure why the client would need to know that in the LCUP case.  I
would appreciate more information about what type of
application you have that would require that information.
<TJH>
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.
</TJH>

>
>
> Regards,
> Mircea Pana.