[
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@eclipse.org_
__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
