I don't want to sound like a grouch, but XECS-1305 seems to me to be very problematic.
The original redirector interface was designed with the idea that the various redirectors each, independently, looked at the request-URI to produce contacts, and the resulting set of contacts was made into a 302 response. Even then, this design principle was violated (in how fallbackrules were handled, in the exstence of "post-processor" redirectors, and in the fact that a redirector could return an error that overrides all other redirectors). But this principle is the sort of thing that improves software architecture, as it allows redirectors and their effects to be discussed without having to always reference the order in which they are executed. 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? 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. >From a theoretical point of view, choice 2 means that we still don't have to worry about the order of execution of redirectors, even with "authoritative responses". From a practical point of view, we can omit the "authority level" machinery entirely, because the code knows that when a redirector declares its response authoritative, no contacts will have come from any other redirector. 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
