Hi Shawn, > I don't know - MS has changed global IE handling of other W3C > standards and RFC recommendations (the http authentication > scheme is a good example).
Actually, this is a debated issue... RFC recommendations can be distilled into: http://rfc2396.x42.com/#s3.2.2: "Some URL schemes use the format "user:password" in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used." http://rfc1738.x42.com/#s3.1: "An HTTP URL takes the form: http://<host>:<port>/<path>?<searchpart> where <host> and <port> are as described in Section 3.1. If :<port> is omitted, the port defaults to 80. No user name or password is allowed." http://rfc2396.x42.com/#s3.2.2: "http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]" But let's not get started on that one as well :) > To blindly trust that MS would not change XML parsing to > break processing of > in attributes is a scary proposition, IMO. And that's not what I meant to propose. What I meant is that the number of pre-defined entities, that cannot be literally used, is fairly low -- I think there's four or five of them (see http://tech.irt.org/articles/js212/#predefined_entities). I think an extension of these is highly unlikely. > The other difference is that a management UI doesn't have to > get loaded just to 'turn on' DQSD. It gets loaded on command, > when the user want to do editing. A brief delay is expected > when loading non-core portions of an application. Adding the > necessary XML processing to the base initialization could > delay it more. This is a valid concern. We would have to test it, and see how it compares. > Okay. Let's take this from another angle. Someone joins the > users group and needs help changing settings. If we have a UI > it will offset the confusion a bit, but I don't think there > are easier ways than telling someone "add this line to localprefs.js: > variable=value;" My whole rationale for moving the config files to XML is to make them easier to machine-edit, so we can build a powerful configuration UI. If we don't have a UI to offset the confusion a bit, I don't think we should do this at all. Well, maybe for the aliases :) > Perhaps a conversion to XML would make more sense if we > provided each search the option of building it's own > configuration interface. > For the above search the config form would provide a simple > row-by-row selection form and autoappend an empty bottom row > when the next empty row was used. Beside it would appear > option buttons to let you select the default config to apply. If we're really clever when we define the schema for the prefs file, I think this could just as easily be performed in the main UI. Actually... Come to think of it, we can support both. Since all prefs in preferences.js are simple values, we could move those to preferences.xml, provide a user-hook with localprefs.xml and support localprefs.js for users like yourself. The JavaScript prefs would not be editable from a UI, but rather require hand-tweaking, since they will likely be complex enough to be difficult to manage without a text editor, whereas the XML settings could easily be exposed in a simple about:config-like UI. Much like IE Options vs the Registry. - Kim ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Archive: https://lists.sourceforge.net/lists/listinfo/dqsd-devel
