|
From: Nicholas C. <ni...@cc...> - 2003-01-21 16:08:00
|
On Tue, Jan 21, 2003 at 10:34:43AM -0500, Wizard wrote: > > I agree that looking to the future is good but since it will be a major > > upgrade to use a different backend or whatever I would suggest that as > > long as we have the file IO in a module that provides a standard > > interface, the implementation can be changed at any time. > > > > Munging the datastore to fit whatever new strategy you want to use > > should be straightforward. > > I honestly could care less about XML, but I thought that being an in-use > standard might lead to greater acceptance over a proprietary format. It's > 'Give the people what they want', as far as I'm concerned. What is it they > want? For some reason I have this gut dislike of saying that something is "XML" (which has a well defined spec) but then implementing a parser that can only read files formatted in our way. (for reasons of speed/size/inlining) The only concrete reason I can see for suggesting that it would be a bad think to have an XML message file is that we make it look like the site admin can download the message file, edit it in something that reads XML happily to "correct" something, and then upload the edited XML back to the server. And their XML editor has written out XML consistent with the schema that our output XML implied. Only it's not quite the same (is order allowed to change?) and our script barfs. And they hassle the support list about this. And we say "but you're not supposed to do that" and they reply "but you say it stores it as XML. And what I gave it *is* XML" Whereas if we have a clearly proprietary format abstracted nicely behind a flexible interface, then we can change from our format to XML to a relational database to trained monkeys whenever we feel like it. Nicholas Clark |