Threading

[Johannes Lichtenberger <jo...@uni-konstanz.de>]

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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org