On Mon, 2008-09-29 at 19:17 +0000, Scott Lawrence wrote: > We do not have the alternative available of going back and getting rid > of those possibilities - our only choices are to make the mechanisms > incrementally better.
I agree that there are a lot of improvements in the proposed interface, and I don't want people to think that I'm against those. And opening up the possibility of eliminating forwardingrules.xml as a special function is a major improvement. > Roberts proposal actually goes further than I had originally asked for > by limiting what a redirector can do to the response message - it can > now either specify an error or manipulate the contacts, but it can't > change other parts of the response (and there are some seriously ugly > possibilities there now - fortunately, we have resisted using them, but > the possibilities exist). This is a narrowing of what a redirector can do to the "rest of the message" but it seems to be a widening of what at least some redirectors are expected to do to the contact list, especially remove contacts that were added by previous redirectors of lower authority. What's bugging me is that we're adding quite a lot of machinery to how redirection works but I don't see that we've thought through and enunciated what redirectors are expected to do, and updated our mental models of how redirectors operate, and then aligned the interface with that set of expectations. As just one instance, we seem to no longer expect redirectors to be side-effect-free. (Do we expect that that they can be re-executed without harmful effects?) Currently redirectors: - are "contact-generating" redirectors, which can: -- add contacts -- test if there are currently any contacts (That's badly structured, but that's how it stands.) -- in some cases, signal errors regarding the request-URI - or are "editing" redirectors, which examine and modify the contacts (though they do not add or delete contacts, or signal errors) -- and some editing redirectors have side effects beyond the response to the message (Maybe these form a third class of redirectors?) In addition: - all of the contact-generating redirectors have to execute before all of the editing redirectors - the contact-generating redirectors that are sensitive to whether there are already contacts have to follow the correct set of contact-generating redirectors (uck) - the editing redirectors have to be executed in a particular order, and after the contact-generating redirectors Fortunately, most of the ugliness is that the redirectors have to be executed in a certain order, which is fairly cleanly captured in how the configuration file is structured. What we're looking to add to the redirector system is being able to turn into redirectors the clauses of forwardingrules.xml that do not send the request to the registrar. That is inherently (already) a situation of "apply rule A, and if that doesn't apply, apply rule B", which always leads to ill-structuring. But of course, that's the effect of forwardingrules.xml already. So we're proposing to add an "authority level" to each redirector, and if an redirector at one authority level takes action about a request, then the redirectors at lower authority levels have no say about the request. (Implicitly: There can be several redirectors at one authority level, which are equal. A redirector can signal that it has taken action on a request without providing a contact or error for the request.) Ideally, we want to have the redirector server infrastructure handle the authority levels, so the redirectors don't need any supporting code (which would be slightly different in each redirector and prone to errors). This differs from the current proposal in that the current proposal doesn't completely encapsulate the authority levels away from the redirector code; instead it expects the redirector code to know and implement the prioritization of contacts. But that would allow redirectors to also edit the contact lists in ways incompatible with the authority levels. Let me sketch a modification of the proposal: We keep the ordering of the redirectors as we have it. This is used to enforce that editing redirectors follow contact-generating redirectors, that contact-generating redirectors follow the proper other contact-generating redirectors, and that editing redirectors are executed in the proper order. (Not so pretty, but we're doing all this already.) Add to each redirector a declared authority level. Admit that redirectors may have external side effects, but require them to be re-executable (so that re-starting the redirector chain doesn't cause problems). As the redirectors are executed, have the redirector server keep track of the current contact list, but also keep track of the "highest authority level of any redirector that has expressed interest in this request". Implicitly, the current contact list elements are tagged with that authority level (as when a higher-authority redirector expresses interest, the previous contacts are deleted). Similarly, the server keeps track of "the current error response", which is also implicitly tagged with the current authority level. As the server is cycling through the redirectors, it keeps a state which is the accumulation of the responses of the redirectors which share the highest authority level for which any redirector has so far expressed interest in the request. Responses from redirectors of lower authority level are deleted from the accumulation. This allows the server to optimize by skipping any redirector whose authority level is less than the current authority level. Redirectors can: - declare their lack of interest in a request (which causes no change to the server's state) - return that they are interested in a request (which raises the tracked authority level, and also deletes any stored contacts/error of a lower authority level) - add a contact (which raises the tracked authority level, ...) - declare an error for the request (which raises ...) - test whether there are any contacts *at this authority level* (because responses at lower authority levels do not affect redirectors of higher authority levels) - iterate through the list of contacts and examine or edit each contact and the current error (at this authority level or lower) (Perhaps this ability should be gated by an additional configured attribute of each redirector? Actually, redirectors that do this operation don't do any of the above operations, and vice-versa.) I think this gets us everything we want, without requiring/allowing the redirectors to correctly delete superseded elements from the contact list. The current editing redirectors can be accommodated (I think) by placing them at the end of the redirector list (as they are now) with a high authority level. Two redirectors that implement logic like "try A, and if that doesn't work, try B" can be implemented by putting A before B, and giving A a higher authority level than B. (Actually, as I've defined the machinery, their execution order is irrelevant, but it's more efficient to put B later.) And perhaps this trick can be exploited to eliminate the "test whether there are any contacts" operation (which is an irregularity I don't like). (I'll have to think about that.) Going back and comparing to Robert's version, I don't think I'm proposing much of a change, mostly moving some of the action of "Subsequent plug-ins in the chain of equal or higher 'Authority Level' will get to edit the Contact list" into the redirector server. But this version enforces a tighter set of expectations on the redirectors, (hopefully) based on an assessment of what the redirectors need to be allowed to do. And there's another change: Declaring an error for a request is handled much like declaring a contact for a request, in that it can be overridden by a higher-authority redirector. More later, 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
