I think the jobs-specific code should go in the jobs bundle. It may not end up taking the exact form of the prototype, but having a job-based executor in the jobs bundle makes sense to me (it may just be added to IJobManager rather than a separate class, but that's an implementation detail).
I am a bit worried about casting this API in stone for Galileo though. It has had a lot of discussion, but until it gets used in real scenarios, I'm not 100% confident in the shape of the API. Keep in mind the API freeze is about 8 weeks from today... I recall from when we added the jobs API, we had an initial prototype API in 3.0 M1 and it took nearly the entire release cycle to get it right. I think the future API is starting off with a lot more experience behind it, but it may still need to evolve as we discover how it is integrated into existing code, how it interacts with GUI code, etc. Given that everyone has their heads down getting their own feature work done, I don't think that integration will really happen until the next release. I would be in favour of adding it as provisional API in this release with the intent to make it real in the next release. John Thomas Watson <tjwat...@us.ibm.com> Sent by: equinox-dev-boun...@eclipse.org 01/15/2009 10:45 AM Please respond to Equinox development mailing list <equinox-dev@eclipse.org> To Equinox development mailing list <equinox-dev@eclipse.org> cc Subject Re: [equinox-dev] a future with futures How big is the code? I got the impression that is is not going to be that big (perhaps 20k or less)? I agree with Pascal that it would be nice to separate this into another bundle, but I would like to avoid splitting it into a whole bunch of very small bundles. Would it be possible to move JobsExecutor and RealmJobsExecutor into the jobs bundle and have jobs depend on the new equinox futures package? The other option is to have optional dependencies on jobs, but I think it is cleaner to put them into the jobs bundle. If we moved the jobs related classes to jobs the package could be something like org.eclipse.core.jobs.future. I am fine with org.eclipse.equinox.future as the bundle/package name. Thoughts? Tom Scott Lewis ---01/14/2009 09:25:49 PM---Hi Pascal, From: Scott Lewis <sle...@eclipsesource.com> To: Equinox development mailing list <equinox-dev@eclipse.org> Date: 01/14/2009 09:25 PM Subject: Re: [equinox-dev] a future with futures Hi Pascal, I'm willing to do this, if this is the consensus...but it would probably then need to be two bundles...since the two jobs-dependent classes (JobsExecutor and RealmJobsExecutor) would best be isolated from the rest (which only have deps on org.eclipse.core.runtime). What package naming do people suggest? Thanks, Scott Pascal Rapicault wrote: > > The code seems to be relatively well isolated, why not create a new > bundle for it? > > Inactive hide details for Scott Lewis ---01/14/2009 07:17:19 PM---On > this E4 enhancement request: https://bugs.eclipse.org/bugScott Lewis > ---01/14/2009 07:17:19 PM---On this E4 enhancement request: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=253777 > > > From: > Scott Lewis <sle...@eclipsesource.com> > > To: > Equinox development mailing list <equinox-dev@eclipse.org> > > Date: > 01/14/2009 07:17 PM > > Subject: > [equinox-dev] a future with futures > > ------------------------------------------------------------------------ > > > > On this E4 enhancement request: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=253777 > > there has been a long and fruitful discussion about supporting > asynchronous programming (for E4 as well as other projects including > ECF, p2, DSDP) by adding the concept of a 'future' to Equinox. Various > designs have been proposed, and I think that there has been a good > amount of convergence recently...i.e. see comment 121: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=253777#c121 for a recent > summary. > > I would like to request that this contribution be considered for > addition to Equinox for the Galileo release cycle. If there is > more/other that I can do as a contributor please let me know. > > Scott > > _______________________________________________ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev