Generalizing the File Uploader - Work Queue component

Colin Clark colinbdclark at
Tue Jan 5 18:25:04 UTC 2010


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.



Colin Clark
Technical Lead, Fluid Project

More information about the fluid-work mailing list