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 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. Carolyn _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
