> > On Fri, 2008-09-26 at 13:29 -0400, Joly, Robert (CAR:9D30) wrote: > > > > On Fri, 2008-09-26 at 09:52 -0400, Joly, Robert > (CAR:9D30) wrote: > > > > > I agree the return codes should be improved upon. Let me > > > > take another > > > > > crack at it. The descriptions I provide below explain > > what each > > > > > return code means from the point-of-view of the redirector > > > > plugin (i.e. > > > > > represents what would be found in the interface > > comments). As a > > > > > result, it does not discuss the whole business of > > 'authority level' > > > > > since this is a concern for the RedirtectServer and not the > > > > plug-ins themselves. > > > > > > > > > > SUCCESS_LOOKUP_DONE = the request was of interest to the > > > > > redirector and it asserts that the content of the > > returned Contact > > > > list meets its > > > > > requirements. > > > > > > > > > > LOOKUP_SUCCESS_SKIPPED = the request was of no > interest to the > > > > > redirector and as a result did not modify in any way > > the content > > > > > of the returned Contact list. > > > > > > > > > > LOOKUP_ERROR = the redirector reported an error. The passed > > > > > ErrorDescriptor may be used to customize how that > error will be > > > > > communicated back to the originator via a SIP response > > > > > > > > > > LOOKUP_SUSPEND = the redirector needs the request to be > > > > suspended for > > > > > asynchronous processing. > > > > > > > > I like your descriptions, but the names need a bit of > > work so that > > > > they reflect what the result is... what do you think of > (for the > > > > same 4 as above, in order): > > > > > > > > LOOKUP_FOUND_CONTACTS > > > > LOOKUP_NO_CONTACTS > > > > > > There is a subtlety here that is lost with the 'NO_CONTACTS' > > > terminology but I'm not convinced that the subtlety is > > important in the first place. > > > Let me state what it is and you can decide. In the > description of > > > SUCCESS_LOOKUP_DONE, I purposely avoided mentioning that the > > > redirector 'edits' the contact list. The return code is > not saying > > > that it has provided any additional contacts, it is just > > saying that > > > it is satisfied with the Contact list. This effectively > allows the > > > plug-in to bring a contact list to its authority level even > > if itself > > > didn't contribute (or > > > found) new contacts as part of the look-up. The redirector > > authplugin > > > is one such example where it does not find any contacts - > it simply > > > modifies them as needed. Having that plug-in return a > > > "LOOKUP_FOUND_CONTACTS" may be counter-intuitive. It is > > possible to > > > imagine an even more dramatic theoretical example whereby > a plug-in > > > does not even edit any existing contacts but just wants to > > 'bless' the > > > current list with its authority level. In this case using > > > "LOOKUP_FOUND_CONTACTS" would be very confusing. > > > > It's worth it to get the right names: > > > > how about: > > > > LOOKUP_ERROR > > LOOKUP_SEARCH_PENDING > > LOOKUP_CONTACTS_UNCHANGED > > LOOKUP_CONTACTS_MODIFIED > > That works for me. >
Scott, I know that the approach I'm proposing hasn't been officially approved yet (waiting for Dale's reply to your previous post) but I'm starting to prototype this now to get ahead of the game. My first order of business was to change the return codes throughout and I quickly came to a realization. Basically, we now offer two 'success' return codes: CONTACTS_UNCHANGED and CONTACTS_MODIFIED. Supporting the two success codes requires re-opening every redirector and making sure that it returns the right error code based on whether or not it found contacts. Although this operation is mechanical and trivial, it is somewhat error-prone. I could see someone creating or modifying a plug-in to return more contacts and forgetting to set the return code to CONTACTS_MODIFIED. The whole point of having two 'success' codes is to let the redirector server know that a given plug-in modified the contacts. It seems to me that the same result could be achieved if there was a way for the redirector server to interrogate the returned Contact List to find out if modifying calls were made by the last plug-in. This way, the plug-ins would continue to report a single 'success' code eliminating the chances of returning the wrong one and keeping their return-code-setting logic very simple. So, here is the amendment I propose to the original proposal: 1- Return to a single 'success' return code: SUCCESS. 2- Instrument the editable Contact List that the redirect server passes to plugins to track whether or not modifying calls were made. 3- After a redirector is called and returns 'SUCCESS', the redirect server will interrogate the Contact List to find out if new modifying calls were made. If so, the authority level of the plug-in will be applied to the list, otherwise, it will keep its existing authority level. I think this is a must cleaner approach that achieves the same end- result and that has the advantage of concentrating the logic of handing the two possible success cases in a single core location. I'm going ahead with that approach in my prototype. Please comment. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
