> Looked at that, seems quite a bit more than what I need, and harder to use > from the point of view of polling. > I'll stick to something more similar to what Gabriel did. > >
Not sure I understand that one; you can poll for the current progress? The progress listener is used between the executing code (if it has actually started) and the value stored in the Progress for other code to check on. > > See above; I was expecting the ProcessExecutor to track this information; > > and the Progress data structure be the core of this response document. > > > > Process wise, we already have the factories pass down a ProgressListener > > among the call arguments, so the process can update its status. > > > > > Yep, that's what I want to use. But Progress is no good, does not allow > for cancellation, does not have the notion of "paused" state > and forces the usage of Future, when doing restartable processes > against persistent storage and checkpoints people should be free to > use whatever they want imho. > > Good point out "paused"; it does actually allow cancelation last I checked. In any case I have not started using ProcessExecutor & Progress yet myself so if a solution is going to be in flux for a while I will hold off taking gt-process to supported status. > A progress listener is all we need. > > Not strictly true as we need something to hold the result (or reference to the result). > > The design is the same; ProcessManager extends ProcessExecutor; Status > > extends Progress. > > > > > > As said above, the interfaces over there do not seem suitable for what I need, > I need interfaces that talk about what can be done in a WPS server allow > for polling state and cancellation. > > Those two are covered; it is the pausing that is not covered. > Afaik the GeoTools ones are probably suitable for a desktop tool instead, but > in practice nothing is using them? > > correct; I have not used them in a desktop tool yet either. > If so maybe we can do like with the processes, port back reusable portions > to GeoTools once the dust is settled. > > In any case I'll keep them on the desk along with Gabriel work and see what > I can learn from them while building asynch support for GeoServer > > No worries; what is your timeframe Andrea? I kind of want this stuff settled before I sink more work into it. Jody
------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
