Stuart McCulloch schrieb: >> Sorry. I've written code with about any XML parser out there and none of >> them would even get close to what DecentXML can do. In DecentXML, there are >> no private fields or methods. Everything is meant to be extended or reused. >> It's meant to be useful instead of limiting what you can do. > > ouch, there's a reason to use private fields, etc. - if you open everything > up then you don't know what people are using and can't be sure that you > don't break them when you change or refactor your implementation
That's a non-issue for OSS software. If a user used something from 1.1 that's gone in 1.2, he has three options: 1. He can chose *not* to upgrade. Nothing forces him to. 2. He can backport the changes he needs from 1.2 3. He can modify his code to work with 1.2. Of course, with closed software, you have no choice but #3. That said, I of course try to make no breaking changes and the information that I offer is basic. It can't be broken down further or aggregated in any useful way with other information, so even if I have to change some internal details, this information will be still around. >> That said, I haven't thought about building Maven on DecentXML and get rid >> of StAX. Pull parsers are a step forward to what we had before (SAX&DOM) but >> they still suck (any parser sucks, pull parsers just suck a bit less). > > *any* parser sucks? does that include DecentXML? ;) It sucks least. For me. :) >> As of right now, there are two reasons not to use XML: >> >> 1. You documents are huge (10MB and more) > > kind of orthogonal to choosing a parser - besides I can write large > documents in any format Well, all parsers that build context for you (so you don't have to track it yourself), need the memory to keep the whole document in memory. That said, I haven't tried DecentXML with a big document yet. I've tried to make it memory conservative (I'm an old C64 guy; I hate to waste bytes), so it won't allocate memory for a lot of things until it has to (for example, if your elements don't have attributes, each element will only need 4-8 bytes for the null pointer) > 2. You must be compliant to some API. > > I actually like APIs, because it gives me confidence I can swap in other > implementations later on You still believe that? ;) Okay ... have you ever tried to replace Xerces with Crimson or the other way around? Both are SAX parsers and both are SAX compliant and if you do, you will have the most strange errors plus some of your code probably won't work because you needed that one feature which wasn't in the standard ... Further more, there usually is one implementation which fits you need so you will never ever do that and any minute spent of making it compatible is most likely wasted. As for DecentXML, I've considered to make it Duck-typing compatible to JDOM (so you can replace the JAR and recompile and you shouldn't have many errors). Didn't have the time nor the pressure, yet. I also considered to make the API compatible to java.util.List to make it more natural to work with child nodes, etc. But that would mean a major breaking change in the API and I'm not sure it's worth the effort. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://darkviews.blogspot.com/ http://www.pdark.de/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
