On Wed, 2009-01-21 at 08:56 -0500, David Saint wrote: > I'm working on http://track.sipfoundry.org/browse/XECS-1590 (RLS > partial state notification) and I've found an issue that appears to > require architectural work in the SIP stack to resolve.
I'm sure it does require architectural work, but I don't see what architecture you're proposing -- all I see is some proposed code changes. The fundamental architecture of the Subscribe Server is close to what RFC 3265 envisioned, that the "resource" has a "state" which changes from time to time, and it is the job of the Subscribe Server to send NOTIFYs to keep the subscribers updated. What this implicitly assumes is that when the "state" changes, *all* subscribers should receive the *same* update. (Subscribe Server elaborates that by allowing the application to supply the state in several different MIME types, but I know of no application that exploits that.) The reality of partial updates violates that model. Theoretically, the Subscribe Server needs to keep track of what state has already been sent to *each* subscriber, and when a new state arrives, for each subscriber, to calculate and send the difference from its former state. Though it's possible that there is a clever algorithm to cut the amount of work. But this means that the Subscribe Server not only has to keep these records, it has to know how to compute the difference between the past state and the new state. We could push all this work up to Subscribe Server's caller, but that doesn't change that the work needs to be done, and it would then be re-implemented in each application. So it's better to come up with a general solution and implement it in the Subscribe Server. One possibility would be that the application, when updating the state, provides two objects: a full state, and a delta relative to the full state of the last update. Then when the Subscribe Server wants to send a NOTIFY to a subscriber, and the situation is such that a partial update is allowed (not in response to a SUBSCRIBE), and a delta object has been provided, the S.S. can send the delta object. This avoids the S.S. having to track the past state as known by each subscriber (as they would all have the same past state), and having to compute deltas. It also avoids having the application be aware of each subscriber individually. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
