Re: Is this really an LCUP show stopper?

Ted,

>                To me, you seem to be arguing below that the
>approach (client pull, optimized by some server state) is invalid,
>when my reading both of the draft and this text would be that this
>approach allows a wide  range of variation in the balance between
>optimizing wire traffic by increasing server state and optimizing
>server scale by allowing for profligate returns.  While I certainly
>respect your sense of the difficulty of implementation this might
>pose to existing clients and servers, I'm not sure how this makes
>this invalid.  It is an engineering balance between two costs,
>and the protocol allows the balance to shift both ways.

Because even a single omission of delete / modify in history can make
it impossible to recreate the previous sync result the cookie of a sync
request refers to, it looks more like a matter of how long the full
history information is maintained rather than how complete the history
information is. That is, as to the completeness of history, it is a binary
decision, not a wide range of variations. How long the full history is
maintained for sync purpose would give a tradeoff. But it still requires
maintaining full history in order to benefit even a small from the 
tradeoff.
It in fact assumes an implementation option and gives tradeoffs only 
within that option.

>                is a good, short precis of your points.  I do see an 
engineering
>disagreement here on how to balance increases in state for
>deployed servers vs. the value it presents.  I don't see a show stopper,
>though, as the draft acknowledges the possibility that maintaining state
>will not be appropriate for all cases and provides other mechanisms for
>them.  That those are sub-optimal from a consumption perspective
>is not exactly surprising, given the basic design.

The concern here is that other mechanisms (full reload / sending excessive
entries) would be the norm for most cases.

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