> -----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 _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
