[jdom-interest] JDOM as a Database API?

[Brett McLaughlin]

Gerardo Horvilleur wrote:
> 
> Brett McLaughlin wrote:
> > I'm very much against this, for several reasons.
> >
> > First, the core principle of JDOM is that it is an in-memory structure,
> > and is pure Java objects until it is outputted, and inputted. In other
> > words, a document doesn't have to be well-formed, valid, etc., except
> > when inpit and output occurs. Not tying the in-memory representation to
> > XML, databases, or anything else keeps us portable, light, and udeful.
> >
> > Second, and building on that, you add a tremendous amount of overhead to
> > every call. Writing to a database, actually checking the database
> > schema, and all the problems you incur with this behavior make JDOM a
> > heavyweight API in this case.
> >
> > Third, you abandon all portability. I should be able to build a JDOM
> > Document from any input form, manipulate it in the same fashion, and
> > output it to any supported output form. This ability to move from one
> > input (SAX, DOM, JDOM, RDBMS) to the /same/ internal representation, to
> > any other output format (SAX, DOM, JDOM, RDBMS) and chaining the calls
> > is what, IMO, makes JDOM really cool.
> >
> > While certainly you can do what you are wanting (it is open-source!),
> > I'm suggesting that you not, and rethink your decision; adding input and
> > output from a database is something I'd like to see, but adding
> > automatic committal, etc., isn't something I would endorse or want to
> > encourage users to do (i.e. by putting it in jdom-contrib). Think it
> > over, and I think you'll see that input and output are better ideas.
> 
> I can't say I agree with you.
> 
> But on the other hand, I do like JDOM's ease of use and I believe you might be
> right in being so reluctant to accept any extensions which could compromise its
> simplicity.
> 
> As it turns out, although I really like the idea of using JDOM as a database API
> I don't need this right away. So I will think carefully about it, and if I still
> think it is a good idea I will write a design document explaining why I need it
> and how I intend to implement it. Then, before I do anything else about it, I'll send
> this document to you (and anybody else you tell me to) so I can get your feedback.

Excellent - send it to this list, and we can all talk about it and
discuss it. And like I said, it may be that a compromise, using input
and output, works great, and that would be core API. We'll see...

Thanks for being willing to work at the design - that's a sign of wisdom
;-)

-Brett

> 
> Is this OK with you?
> 
> --
> 
> Gerardo Horvilleur
> mago at mail.internet.com.mx

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org