Scott wrote: > 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.
Reusing parts of the RLS code will of course require an understanding of its code architecture. I've spent some time looking at RLS, and have a very good understanding of its functional role. But my comprehension of the RLS code architecture lagged behind where I would have expected. Object-level descriptions of the flows through the code could help open up that understanding. I'd suggest the following scenarios: - Start-up: initial - Start-up: with active resource list subscriptions - New AOR-contact registration occurs (reg event NOTIFY received) - BLF event occurs (dialog event NOTIFY received) - Client subscription (resource list SUBSCRIBE received) - Configuration change: new resource list added - Configuration change: existing resource list modified Someone who has a good understanding of the above scenarios would be in a better position to reuse RLS code to build an AppearanceAgent. -Paul [email protected] _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
