[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] a future with futures

Hi all,

Although provisional API (for 1.5 years) seems a bit conservative...and it will cause ECF/other potential clients of the API difficulties over this time (i.e. we would like to have our ECF 3.0/Galileo release of remote services use this API)...I understand and can certainly live with this decision.

So if I understand it correctly the approach is to be:

1) new plugin with id: org.eclipse.equinox.future
2) API package name: org.eclipse.equinox.internal.provisional.future
3) JobsExecutor and RealmExecutor in org.eclipse.core.jobs bundle, in a new package: org.eclipse.core.internal.provisional.jobs.future


Is this right? If so I will create the described new plugin, and submit new patch that includes this plugin on the enhancement request.

A question: For the test code, where (in the equinox test cases) should the test code go? Should it have a new test plugin as well? What about the JobsExecutor-based tests? Should these go in the jobs test bundle or somewhere else?

Thanks,

Scott


Thomas Watson wrote:

I agree with John. This should likely be provisional API or should be worked in the e4 context with an eye to backport to the 3.x line once we are confident in the API.


Tom



Inactive hide details for John Arthorne ---01/15/2009 10:39:51 AM---I think the jobs-specific code should go in the jobs bundleJohn Arthorne ---01/15/2009 10:39:51 AM---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 havi


From: John Arthorne <John_Arthorne@xxxxxxxxxx>

To: 	
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

Date: 	
01/15/2009 10:39 AM

Subject: 	
Re: [equinox-dev] a future with futures

------------------------------------------------------------------------




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



Inactive hide details for Scott Lewis ---01/14/2009 09:25:49 PM---Hi Pascal,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@xxxxxxxxxxxx
__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