Hi,
I've thought about it and I think the simplest and fastest way to
process a very regular XML file (shreddered) out of native database
system is to build a datastructure with Threads. The xml file looks
like:
<pictures>
<picture>
<name>...</name>
<thumbUrl>...</thumbURL>
...
<sentiment>...</sentiment>
</picture>
<picture>
...
</picture>
...
</picture>
So I can create Threads for every picture-element and build
Picture-Container (A simple linked or twin-linked list of Nodes (name,
sentiment, thumbUrl...) in a TreeSet so it's sorted according to
sentiment or something).
With a ThreadPool I can also wait until all threads have terminated
and then write a startDocument(...) SAX-Event and the Transformer
reads it and does something with the pictures and create SAX-Events
for an XSLT-Transformer, which in the end creates a KML file out it.
Do you think that it's rather a "hack" or something because it doesn't
really send SAX-Events (despite of a startDocument(...)) to the next
Element in the pipeline (namely the first Transformer)?
Our task is to visualize images from flicker in Google Earth, so I
think I can reimplement the Cocoon things, so that we can think about
the "real" problems (think about an algorithm which reduces
overplotting and so on).
Well, at least I think the vision of Cocoon3 is that everything can be
used or pipelined to the next component (e.g. SAX, StAX ...) so in our
case it's a datastructure.
Ok, I just thought about it another time and the datastructure could
be huge, so maybe it's not the best idea, but I'll think about
collecting SAX-Streams in the threads (or maybe just don't implement
the thread thing because I know what is the main bottleneck in my
Generator (namely a DescendantAxis instance for every picture which
isn't fast enough).
regards,
Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
