On Wed, 2009-05-27 at 10:56 -0400, Carolyn Beeton wrote: > I'd like to solicit opinions on whether building an AppearanceAgent by > reusing large parts of the RLS code is a good idea or not. It seems to > me that the problems are very similar, with the AppearanceAgent having > perhaps one less dimension than the RLS: instead of having multiple > ResourceLists each containing a set of Resources, we have one list of > AppearanceGroups (shared URIs), each containing Appearances (added > dynamically as sets register to the shared appearance URI). A lot of > the subscription management and publishing infrastructure can be used > pretty much intact.
I think it's a good idea - the problem spaces overlap, and there's a lot of infrastructure that it would be silly to duplicate. > I have been able to coerce the RLS into driving Polycom sets (they > implement draft-anil-sipping-bla-02) and can demonstrate passing a call > back and forth using Hold. At this point it is just a kludge: I am just > reflecting the body of the Notify provided by the set to all sets which > subscribed to the shared line. Before I invest any more time in the > specifics I'd like to hear the group's opinion. > > I would also like to make something which would have an evolution path: > Polycom implements draft-anil-sipping-bla-02 and has no plans to move to > anything else, but a newer version of that draft exists (just for fun > they changed the name of the event package sets subscribe to; don't know > if any sets implement it), and there is a new > draft-ietf-bliss-shared-appearances in the works also. It seems that > the reality will be a mix of stuff out there. "Standards are a good thing - we should have lots of them." (paraphrased from a former chair of IEEE 802) _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
