> On Thu, 2008-09-18 at 16:17 -0400, Joly, Robert (CAR:9D30) wrote: > > > But XECS-1305 seems to entirely abandon the idea that redirectors > > > are independent of each other, and that their order of execution > > > does not matter. > > > > > > There seems to be at least two ways out of this conflict: > > > > > > 1) Re-assess whether there is any requirement for XECS-1305. > > > I notice that no use cases are provided for XECS-1305 -- perhaps > > > this functionality is not really required to solve the ultimate > > > problem? > > > > Scott has a much more comprehensive view of the trajectory of > > redirector plugins than I do so I will let him field that > question but > > it is a very legitimate one. > > I'd still like to see a use case for XECS-1305. > > > > 2) Add constraints to the redirectors that enable the sort of > > > operations that are envisioned, without making the > outcome dependent > > > on the order of operations. For instance, if a > redirector gives an > > > "authoritative response" for a URI, we might require as a > validity > > > constraint on the overall configuration that no other redirector > > > will provide any contacts for that URI. > > > > I think that the main goal of the original plug-in interface was to > > limit the interactions between plug-ins in such a way that it would > > theoretically be possible for someone to implement a new plug-in > > independently without having to concern itself with the existing > > plug-ins. I think that approach #2 you describe above also > abandons > > that idea. If I understand correctly, when adding a > plug-in, one may > > have to code logic that will ensure that it will not > produce a Contact > > for a given URI if another existing plug-in is known to produce one. > > Building the code that will make that determination > requires knowledge > > of all other plug-ins and/or their configuration hence introducing > > interdependencies, does it not? Besides causing > interdependencies, I > > think that this principle would also be difficult to adhere > to and to > > enforce in each plug-in. I guess that the first violator of that > > principle would be authrouter plugin which needs to go in > and modify > > every "authoritative responses". > > My attitude is that if one would have to add code to one > redirector to consider what another redirector has done, one > has made a mistake in the design. E.g., all redirectors > implicitly act only on certain user-parts, and if one > redirector requires that another redirector not act on a > particular user-part, those redirectors should have > syntactically distinct sets of user-parts that they act on. > > > One curious aspect of these issues is that the current design > allows a redirector to declare an error for a particular > request, which perforce takes precedence over any contacts > that other redirectors have provided. > Currently, the only redirectors which can produce errors are > ones which we have designed to not overlap in user-parts with > any other redirectors. > > > In regard to the current proposal, I think some details are > omitted. I see this text: > > > When a redirector plugin returns SUCCESS_LOOKUP_DONE, the > > RedirectServer will tag the entire Contact list with the Authority > > Level of the plug-in. > > But to make this work as intended, it seems that the > redirector framework needs to delete any other contacts added > by a lower-authority-level redirector.
The way I envisioned the redirectors working, such an operation wasn't necessary. Let me explain. When a redirector performs a look-up, it is at full liberty of editing the Contact list the way it feels and that includes the ability to remove Contacts contributed by 'inferior' redirectors if the function it is trying to provide required it. The bottom line is that the Contact list coming out of a given plug-in contains all the elements that it wanted therefore all the elements of the list are equal at that point. The framework should not take out any contacts as it has no way of knowing which ones it can safely take out - only a plug-in can have such knowledge. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
