Generalizing the File Uploader - Work Queue component

Jonathan Hung jhung.utoronto at
Tue Jan 5 18:57:02 UTC 2010

Thanks Colin, that's great news.

Yes, reporting progress isn't going to be perfect and I guess it's the
nature of the beast. I think when you're talking about a job that takes
possibly hours, an estimate that's a few minutes off won't be terrible (not
great, but tolerable). I think as long as everything is communicated clearly
so there's a clear level of expectation, I don't think the user will mind.

So I don't think there will an incremental progress indicator. Instead it
will likely be a "busy" bar / spinner and updating status text.

>From the client side, we'll need some way of checking the status of a job.
Not sure if that's available currently. Also, I need the steps clarified in
the Export process. I suspect there is more processing after the page-level
processing, but I don't know what they are or how long it takes.

Queuing is important for batch operations in Decapod. It's one of the use

I've attached the mock-up of the batch export interface.

- Jonathan.

On Tue, Jan 5, 2010 at 1:25 PM, Colin Clark <colinbdclark at> wrote:

> Jonathan,
> On 5-Jan-10, at 12:53 PM, Jonathan Hung wrote:
>  In mocking up the interface, I realized it had many of the qualities of a
>> File Uploader:
>> - a queue of items to be processed
>> - a progress / status indication
>> - add items to the queue
>> - stop, cancel, delete work in a queue
>> I'm wondering if it would be possible to use the Uploader to create this
>> interface for Decapod? I'm calling it a Work Queue pattern, but maybe
>> there's a better term.
> The Uploader's progress and queuing features were specifically factored out
> into separate components, with the intention of ensuring that they're
> loosely coupled and reusable. I suspect there are a few lingering
> file-specific concepts in FileQueueView that would need to be refactored a
> bit in order to support job queues, but I think it should be fairly
> straightforward.
> The real question, technically, is how we can receive progress information
> from the server side. Last I heard, Thomas was unable to provide any
> indication of the progress of a processing job. His suggestion was for us to
> calculate progress based on the average time to run for previous, similar
> jobs. Not something that I think is very kind to the user, since any number
> of variables may cause a job to be slower than the average.
> This job queue UI suggests that we'll need a specific notion of queuing and
> scheduling on the server-side as well. It's not a feature currently
> supported in the CherryPy server Thomas built for us, but it's something we
> can certainly add. Not easy work, but it sounds pretty useful.
> Thoughts?
> Colin
> ---
> Colin Clark
> Technical Lead, Fluid Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v9 - Dashboard-Export-01.png
Type: image/png
Size: 64444 bytes
Desc: not available
URL: <>

More information about the fluid-work mailing list