Re: [equinox-dev] a future with futures

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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 <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

01/15/2009 10:45 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
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 <slewis@xxxxxxxxxxxxxxxxx>
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
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 <slewis@xxxxxxxxxxxxxxxxx>
>
> To: 
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> 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@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>   

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev