river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: New version of TaskManager
Date Sun, 19 Sep 2010 21:56:29 GMT
I think we should change the target to 1.5 now, so as not to hamper 
development, then look at how the proxy's and Service API can be 
compiled separately with 1.4.

Patricia Shanahan wrote:
> Now that things seem to have stabilized a bit, I'm working on 
> integrating my TaskManager changes into the latest trunk.
> At this point, I have to make a decision about 1.4 support in 
> TaskManager. It affects two issues, on internal and one part of the 
> interface.
> 1. Can I use an enum to represent a Task's state?
> Currently, it is private to the TaskManager implementation, useful for 
> working out how to deal with task removal. It is something that some 
> TaskManager users might find useful in the future. For example, 
> TaskManager.Task could be given a useful toString that would display it.
> 2. Can I use Iterable<Task> as the type for passing the tasks to check 
> to runAfter?
> This is widespread. The current implementation can use 
> Collection<Task> relatively easily. However, it does commit to it 
> being an actual Collection, which would constrain future TaskManager 
> implementations. Iterable<Task> promises only the ability to construct 
> an Iterator<Task> that iterates over the relevant tasks.
> I'm currently assuming the answer to both questions is "yes", but if 
> so we need to change to compiling TaskManager and its clients with 
> target 1.5 or later, not jsr14.
> This is an advance warning. I'm doing the integration and testing in 
> my skunk patsTaskManager branch. I'll allow time for discussion before 
> committing to the trunk.
> Patricia

View raw message