ext Sofie Lassborn (TN/EAB) wrote:
Hi Jari,
I have some more questions regarding the last paragraph. Please see
below.
Best regards,
Sofie
Chapter 4.7, second paragraph
It is unclear to me what is meant by "...it MUST fall back to sending
all component changes again for this resource." Is the intention that
the server shall send a "full response" as in an initial notification
(my preferred interpretation)? Or is the intention that the server
shall send several notifications with the patches not aggregated?
Best regards,
Sofie
The latter, after sending the http reference, the server does not know
when the client has really read the content, thus no aggregation allowed
with "rapidly changing resources"
[Sofie wrote:]
I see aggregation as very useful in conjuction with rate limitation and
throttle. An issue arrises though when a notification with aggregated
patches becomes too large. According to you the notifier should then
send all patches separately in several notifications but if rate
limitation or throttle is being used the client might never catch up.
Could it instead be the choise of the notifier if it wants to send a
notification with only the document link (content indirection) or if it
wants to send all patches separately?
thanks,
Jari
Sorry, probably i've been unclear on this. Rate limitation/throttle
combined with patching is indeed challenging but doable. And even you
can combine filtering here in addition to standard authorization so the
complexity begins to be quite high (although i could say that even the
basic authorization handling is hard enough to implement, be it on
server or client ;-)). So the notifier must be well aware of the client
state all the time, it is not that one could simply drop some events, so
"throttle engine" and patching process must co-operate properly.
However, related to patching/syncing the key issue is that after the
notifier sends only the http references, it doesn't have the knowledge
when the client eventually has read the relevant resource content. So
once the notifier does this reference sending, it fall backs into the
"xml-patching" mode with full etag change history, i.e. aggregation
_may_ cause similar trouble than during the initial sync. But
subscription refresh (or versioning support in xcap server ;-)) would
similarly solve this.
But anyways, i think that i'll just submit a new version with some
clarifications (and better examples) ?
thanks, jari
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
