Hi Kim, > > (the http authentication scheme is a good example). > > Actually, this is a debated issue...
I know, which is why I tried to steer clear. I was part of an ongoing debate on Full-Disclosure about this for quite a while. My position remains that the host portion of a URL contain the <authentication> portion, as specified in the URL schema, even if it's "not recommended" to do this (and the reasoning behind this is purely *social* in the RFC's, not functional), it still remains as part of the URL schema and, IMO, should continue to be supported by default. MS provides a means to revert functionality via a registry hack, so I'm not exactly furious, but it's not something I'm happy with them about. My point in bringing this up is *not* to debate the RFC's or whether MS was right or wrong. My point is that regardless of whether they're right or wrong, they *did* apply a change that really screwed up applications (like some of mine) that relied on this handling for remote locations to authenticate (I never included the password, only the branch location as http://[EMAIL PROTECTED]/webservice/ ). Another good example would be how MS changed the default behavior of htm files under SP2. For years, literally, people could expect to double click on an HTM file and have it open in a browser. Users install an OS update and suddenly DQSD opens Word or Notepad when the user has their settings to "pagetemplate" variable set. When I develop applications that rely on MS components to function, I remain very wary of what 'exceptions' I trust to remain consistent. Due to their ongoing battles with security and bug-management, MS is the most common offender at changing how things work. I would feel much better about this if we did not rely on their XML parsing engine to process the content. Just because the RFC or the W3 says one thing, doesn't mean MS is necessarily going to implement it that way. Proprietary browser extensions/filters, funky basic HTML handling, that they were already *using* an authentication scheme in the URL to begin with (one way or the other, they either "were" or "are" wrong)... I don't trust that the handling of XML will remain consistent. > 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. I commend that and for the most part I agree; I'm just voicing my concerns. As a hard-core text-based geek I'm still gunning for the ability to be able to use a command-line approach to making configuration changes. I'd really like to see "config var=value" in the next version. > Actually... Come to think of it, we can support both. That's got my vote, as long as it doesn't noticeably degrade the load time. Regards, Shawn K. Hall http://12PointDesign.com/ http://ReliableAnswers.com/ '// ======================================================== Old soldiers never die, they just fade away. -- General Douglas MacArthur (1880-1964) ------------------------------------------------------- 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
