On Mon, 2006-03-27 at 17:13 +0200, Jody Garnett wrote: > Jonas Johansson wrote: > > Hi all, > > > > A Composite Command is handled as a separate thread, but from reading > > http://udig.refractions.net/confluence/display/DEV/5+Composite+Commands > > it is unclear if subcommands are handled serially within the composite > > command or not. Are they? > > > I think so, you must remember that commands are there to produce side > effects (almost like a mini procedural programming language). > I keep thinking of a "processing service" as a bit more functional - set > up the chain of WPS services and punt data in one end ... > > I could however be completely out to lunch.... > > time > > | composite command{ > > | subcommand1 > > | subcommand2 (2 hours) > > | subcommand3 > > V } > > > > I'm thinking that using a WPS as a operation could be performed as a > > series of commands. Depending on the operation, the transfer of data > > between client and WPS server could potentially be asynchronous and take > > a long time. Lets say that the subcommand that would send the request to > > the WPS and receive the results takes 2 hours to complete. I would need > > this subcommand to complete before I do some later commands on the > > results. Is this so? > > > I see where you are going, and it does make sense. You need some actual > infrastructure to "chain" your things together, the command pattern is > suitable when working in chunks of processing like that. > > Let me try to explain my other idea - set up a chain of: > - fetch features > - buffer features > - renderer features to image > - convolve image Yep, such a chain would be nice. But if Composite Commands are *not* serial, I guess one solution would be simply to define a single fat command per opperation and just run that serially. Because the CommandManager assigns commands as separate threads, right? So then it wouldn't matter if I'm adding fetching features, adding layers or whatever in the fat command, because the fat command-thread gets it small bits of time, sharing with other commands. Right?
> The idea being that each feature could make the entire trip from start > to finish - before the next one. > And because I am thinking like a functional language I can do tricks > like divide my query into > two (one for each processor). Well, I guess there are High Performance Computing api:s for Java that simplifies advanced threading, supports dividing tasks into subtasks and parallelizing them etc, JOMP appears to be example. HPC could be used at the client as well as at the WPS. However, that seems a bit overkill for me at the moment. Right now I only buffer one feature at a time per opperation, but I guess selecting many is not far away. Jonas > > Incidentally I saw this bug and thought of you: > - http://jira.codehaus.org/browse/GEOT-153 > > Something to think about when we figure it out. > Jody > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
