[jdom-interest] Streaming JDOM

[Tatu Saloranta]

--- Gregor Zeitlinger <gregor at zeitlinger.de> wrote:

> On 7/18/06, Tatu Saloranta <cowtowncoder at yahoo.com>
> wrote:
> > This is a reasonable direction to take. I wrote
> > StaxMate (http://woodstox.codehaus.org/StaxMate),
> > which does use similar api.
> Yes, it is indeed similar, but do you have examples?
> I could not find getAttribute(name)

Yes, 0.6 had a few omissions. ;-)

I really need to get 1.0 released -- the version in
subversion repository is significantly different from
one downloadable from the page (I had forgotten how
outdated 0.6 was... sorry!)

Anyway, since StaxMate is not really directly related
to JDom, we can take discussion off the list.
I'll also try to find time to post some simple example
code
on my blog (at
http://www.cowtowncoder.com/blog/blog.html);
as soon as I get Woodstox 3.0-final out, I should have
bit
more time for related projects.

> I tried to make my API as similar as possible to
> JDOM, because
> - I think JDOM is easy to use
> - the API should be easy to learn for JDOM users
> - I was hoping it might be included in JDOM
> 
> Regarding the last issue:
> I am wondering if the JDOM implementors do not want
> to have a
> streaming API or if this is just the wrong mailing
> list to ask this
> question.
> Can anybody enlighten me?

I'm not a JDOM implementor per se, but reasons I can
think of
for not getting many responses are:
(and btw, I think this mailing list is just right for
the
questions):

* JDom is a rather mature tree model, and most users
  are either content with it, or moved to
investigating
  more suitable alternatives
* Being a tree model implementation, focusing on
streaming
  may be considered out of scope.
* Implementing any truly streaming mode of operation
that
  maintains convenience of a tree model is quite
difficult
  thing to do.

But regarding "streaming in JDOM", the main question
to me is
what exactly are you trying to achieve?
Efficiency/speed of streaming approach, or something
that is
"just faster than the eager loading"?
There may be other goals too, but from these two,
you'll get
following obvious implementation choices:

(a) Faking a real tree structure by allowing limited
  (one-way, forward-and-parents only, or such)
traversal
  ability.
(b) Implementing what amounts to 'lazy instantiation',
ie.
  only build parts of the tree that one needs

Latter allows full convenience, but generally does not
really
either speed things up or really reduce memory usage.
In common
case, the whole tree still ends up being loaded. At
least that
seemed to be the conclusion of Xerces/DOM implementors
and users.
In former case, usage limitations are such that it's
debatable
whether it's much more convenient than using an
approach that
makes such limitations explicit (such as perhaps using
raw
streaming interfaces). But it can be quite efficient.

-+ Tatu +-


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com