On Thu, 2008-09-25 at 10:16 -0400, Scott Lawrence wrote: > The idea is that most redirectors should be able to be simple - they > should just look at the request uri and see if they have a routing for > it. However, we have some cases in which redirectors look at other > parts of the request and find things that override the routing. > > The current examples of this are implemented as a separate feature in > sipXproxy through the forwardingrules mechanism. My goal is to > eliminate that as a proxy feature and do all routing decisions in > redirectors.
OK, so far, so good. Where I'm coming from is a fear that we're going to let the redirector system degenerate into an entirely unstructured system, where each redirector performs arbitrary editing of the list, and the overall effect can only be determined by simulating the execution of each redirector. It's true that giving each redirector the ability to arbitrarily edit the contact list makes it possible to solve any problem, this is like saying that you can implement any control-flow with GOTO. Control-flows that are implemented with GOTO are fragile. Worse, with GOTO you don't have to think through the overall design of what you're doing, you can just say "At this point, the next thing to do is X" and insert a GOTO X. With "structured programming", you have to get your conceptual model of the code straight before you can write the code. And we already have examples of redirectors that interact with other redirectors in a conceptually incorrect manner (because that was the expedient way to solve the problem at hand). I fear that if the redirector interface allows more arbitrary behavior, people will write redirectors that do arbitrary behavior. > One example of such a usage would be a redirector that takes a (partial) > request: > > SUBSCRIBE sip:[EMAIL PROTECTED] > Event: foobar > > and redirects it to a sipXecs service that mediates access to and > aggregates subscriptions for all 'foobar' events from any user in our > domain (example.com). Now it is (in theory) true that all other > redirectors could be required to _not_ route such a request, but my > preference is that a redirector should be able to be very simple: look > at the address, write contacts. Now this makes my skin crawl. Not because of what you've said, but what you've not said, which is how this redirector relates to the others. I *think* what you mean is "We want a redirector that notices messages with method SUBSCRIBE, Event foobar, and our request-URI domain, and it will provide a contact. And other redirectors should not provide contacts for it." Now, are rules of this sort sufficient to implement everything you want? What sorts of patterns of "which redirector dominates which" are sufficient? Do all redirectors need to have a pecking order, or are there only certain groups that interact? Do we really need all the interactions we now have? Also, how is this alleged sipXecs service going to send SUBSCRIBEs to the real targets? > > 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 have difficulty visualizing how we could (in a reasonable amount of > time) create any programatic enforcement of such a restriction. We don't have to enforce the restriction. But there are times where it is quite useful to simply document as part of an interface "any component must satisfy restrictions X, Y, and Z for the overall system to work correctly". As a trivial example, we require that all redirectors finish executing when they are called, and that is fundamentally unenforcable! But more realistically, even now we require that a redirector will return the same results when called multiple times on the same request. 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
