Yeah, I see your point. It really belongs as some kind of "Remote Communication UI Support" stuff available for all plug-ins. Especially now that ECF is in the SDK via p2.... I could imagine the day when
- update sites, CVS repos, etc. are all using ECF
- all of these things use the same security services (secure storage, a
common authentication UI service)
- they all use a remote job family with it's own download-manager style
progress reporting, meaning all jobs doing remote communication can be
paused/resumed/configured
- a generic discovery view finds all of these services
I'm not passing the buck as far as doing it in p2, but it does make sense
that anyone interested in investigating this problem should try to build it
so that any plug-in using remote communication could make use vs. putting
p2 assumptions in it.
susan
Scott Lewis
<[EMAIL PROTECTED] To: Equinox development
mailing list <[email protected]>
m> cc:
Sent by: Subject: Re: [equinox-dev]
[prov] Participation opportunity
equinox-dev-bounces@
eclipse.org
04/08/2008 11:23 AM
Please respond to
Equinox development
mailing list
Susan Franklin McCourt wrote:
>
> <stuff deleted>
>
> > - User interface for configuring/pausing/resuming/managing downloads
> Do you mean something at the ECF level? Or in p2?
>
Open question about where it ultimately belongs. We (ECF) would like to
have more/better UI support for configuring/pausing/resuming/managing
multi-threaded downloads, and such UI could be applicable to multiple
environs (e.g. RCP, Eclipse, p2 admin, etc). So that might argue for
finding a home for it in ECF. But p2 (eclipse and admin) is the initial
focus.
Scott
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
<<inline: pic31121.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
