Carolyn Beeton wrote: > > >> -----Original Message----- >> From: Lawrence, Scott (BL60:9D30) >> Sent: Friday, January 23, 2009 5:34 PM >> To: Worley, Dale (BL60:9D30) >> Cc: Beeton, Carolyn (CAR:9D60); [email protected] >> Subject: Re: [sipX-dev] emergencyrules.xml - Rules for XML parsers >> >> >> On Fri, 2009-01-23 at 16:58 -0500, Dale Worley wrote: >>> On Fri, 2009-01-23 at 10:26 -0500, Scott Lawrence wrote: >>>> Our policy in the project has been to specify a schema >> for any xml >>>> file that we use, so that we have a formal validation mechanism >>>> (very useful in unit tests and run time configtests). It is >>>> possible for a schema to specify that any element may appear in a >>>> given context, but it is _not_ the default. Few of our >> schemas do so. >>> True, I don't expect a schema to admit arbitrary extensions. >>> >>>> Whether or not our actual xml file parsers tolerate >> unknown elements >>>> varies - some do and some do not. Personally, I think >> that ignoring >>>> unknown elements is usually a bad idea - it means that the file >>>> appears to say one thing but is actually interpreted in >> some other way. >>> But if we don't do that, what is the extension mechanism? Unless a >>> file is specifically designed to carry information from just one >>> program to just one other program -- and both programs are aware of >>> each other's behavior -- you need an extension mechanism >> that allows >>> you to add information to the file without rewriting every reader. >> But that is exactly what the purpose of authrules.xml is - to >> carry one set of rules from one program (sipXconfig) to another. >> >> > > Our auth plugin parsers all tolerate tags within the hostMatch section > which they do not care about (for example, none of them look at the > <description> tag). I don't think introducing a new tag would cause a > problem. > > I have implemented an alternative way of matching emergency rules by > adding a <ruleType> tag to the authrules schema. I added an optional > parameter to UrlMapping::getUserMatchContainerMatchingRequestURI to > further constrain the match to be a specified ruleType. All existing > auth plugins do no such constraining; but the new EmergencyNotification > plugin constrains the match to be of ruleType Emergency. > > I don't see a great advantage either way. The emergencyrules.xml file > is easily generated by sipXconfig, at no great cost. Adding a new tag > to the existing authrules.xml is similarly easy. The new plugin can > look for matches in its own file, or with the above extension, in the > authrules.xml file. There is a slight performance trade-off between > having another file to replicate and load; vs having to skip through > non-emergency rules when checking if a number matches emergency ones > (which I have tried to make as optimal as possible). > > Please let me know your opinions: > - a separate emergencyrules.xml file > - share authrules.xml by adding a new <ruleType> tag > > Thanks, > Carolyn
Whatever makes sense: I do not think there is a big difference in implementation on sipXconfig side: authrules modification seems a bit simpler. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
