> > to me (at the moment) for TopicName being responsible for deciding > what's a > > valid name and what isn't and then have each store responsible for > actually > > encoding/decoding the name in the appropriate store. Not sure how > well this > > At the end of the day, I think this is how it must be...
Agree. I think we need a broad definition of what's legal in a topic name encoded in TopicName. It should do no escaping. Escaping can be done in each context, as we need to be extensible to support different stores - what if someone can't deal with a dot in the name? I like the idea of doing something analogous to IFormatProvider. That would separate out name serialization from the naming itself. But I think it needs to be symmetric, as we want to handle deserialization as well. This could be as simple as defining a TopicNameSerializer abstract base with Serialize and Deserialize methods on it. Or TopicNameEncoder/Encode/Decode, if you prefer. Simple and it'll work. We can even provide a default encoding that does nothing, or uses URL escaping, or whatever. Would have given us a nice place to fix that German millisecond bug. :) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
