On Mon, 2010-03-08 at 12:04 -0500, Scott Lawrence wrote:
> On Sun, 2010-03-07 at 10:00 -0500, Dale Worley wrote:
> > Here's a minor problem that I found while merging the latest Subscribe
> > Server changes into main:  The UtlString::findToken() method is used to
> > look for a string (like "text/plain") in a comma-separated list of
> > strings (like "text/plain,application/octet-stream,text/xml").  The
> > current implementations (plural!) of findToken disagree on whether the
> > specified search string is to be interpreted as a plain text string or a
> > regexp.  This message is to get consensus on cleaning up that question
> > and some related issues.
> > 
> > There are only a few uses of findToken now in the code.  None of them
> > require that the search string be a regexp.  In one of the cases
> > (checking whether a given MIME type is in the Accept list of a SUBSCRIBE
> > request), the search string must not be interpreted as a regexp, since
> > some MIME types have a "+xml" suffix.
> > 
> > Thus, I propose interpreting the search string as a plain string rather
> > than a regexp.  Actually, I propose this as the default interpretation,
> > and that the regexp interpretation will be available by setting an
> > optional parameter, since the regexp functionality can be added with
> > almost no additional work.
> 
> I think and optional parameter is the wrong way to go about that.
> 
> If we need both forms (not clear, given that you can't find any uses of
> the regexp form), then making the method polymorphic (one behavior if
> the search term is UtlString and another if the search term is a RegEx)
> would seem to be better.
> 

Talking to Dale, it would be a flag to distinguish a string that is free
of unescaped regexp characters from a string that may have characters
that need to be escaped.  Between the two of us, we've already hit both
cases.  

-Kathy

_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to