Re: [platform-update-dev] Filters for eUpdate

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

I'm blissfully ignorant of the details
but having a site "type" indicate the transport used to get there
seems bogus.  The type should indicate the format or structure of
the site.

Similarly, it is unfortunate to start
talking about eRCP update sites and having different site types for that.
 That approach will not fly.  Update sites are intended to hold
wads of stuff that people can get and install (whatever).  The intended
use or validity of these wads is not the business of the site itself.  The
site needs to support enough information that clients can efficiently identify
the wads of interest.  If, in the eRCP case, this means somehow extending
the set of information that is available from an update site (either the
physical representation or the interfaces) then that is the discussion
we should be having.  That is not an eRCP vs RCP vs IDE discussion.
 

So lets focus here on what technological
changes are needed in Update to support any new usecases uncovered by the
eRCP work.

Jeff

James D Miles <jdmiles@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

11/15/2005 12:42 PM

Please respond to
"Eclipse Platform Update component developers list."

To	"Eclipse Platform Update component developers list." <platform-update-dev@xxxxxxxxxxx>
cc
Subject	Re: [platform-update-dev] Filters for eUpdate

It seems to me that older RCP clients not being able to
access an eRCP update site would be less of a problem than eRCP clients
accessing RCP sites. I think I should go ahead and implement this way.
I will open an enhancement request for the PDE editor to add the site attribute.

I looked again at the 2 default siteTypes available org.eclipse.update.core.file
and org.eclipse.update.core.http. It seems to me that we should have one
extension org.eclipse.update.core.default or something. Then if the URL
starts with http we would use SiteURLFactory and if the URL starts with
file we would use the SiteFileFactory. The problem is once we start adding
<site type= to the site.xml we are not portable. For instance if I have
an update site on a http server the type would be wrong if I put it on
the local file system. Did I miss something?

Also as best I can tell a site with <site type=org.eclipse.update.core.file
is broken.

Dorian
Birsan <birsan@xxxxxxxxxx>

Dorian Birsan <birsan@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

11/09/2005 11:08 AM

Please respond to
"Eclipse Platform Update component developers list."

To	"Eclipse Platform Update component developers list." <platform-update-dev@xxxxxxxxxxx>
cc
Subject	Re: [platform-update-dev] Filters for eUpdate

I think the problem may be older RCP clients accessing an update site that
uses the new siteTypes. 
Those clients would not be able to use anything from the new update site
(that may be a good thing :-) 

-Dorian

James D Miles <jdmiles@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

11/09/2005 11:59 AM

Please respond to
"Eclipse Platform Update component developers list."

To	"Eclipse Platform Update component developers list." <platform-update-dev@xxxxxxxxxxx>
cc
Subject	Re: [platform-update-dev] Filters for eUpdate

We have existing features which may not have any filters specified. They
were expected to run on anything. We add eRCP and that is not necessarily
true.

Do we expect to be able to intermix eRCP features and RCP features on the
same update site?
The current siteType extension points are org.eclipse.update.core.http
and org.eclipse.update.core.file. If we create new siteTypes for eRCP it
would seem to satisfy the problem of isolating the existing features from
eRCP. If RCP platform could also process the new siteTypes then RCP would
have a shot at using eRCP features.

Jeff
McAffer <Jeff_McAffer@xxxxxxxxxx>

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

11/08/2005 10:56 PM

Please respond to
"Eclipse Platform Update component developers list."

To	"Eclipse Platform Update component developers list." <platform-update-dev@xxxxxxxxxxx>
cc
Subject	Re: [platform-update-dev] Filters for eUpdate

Note that the <feature> filters for os, ws and arch are not recommended.
The problem is that they do not list triplets but just lists. For example
linux, win32, carbon is not a valid configuration but could be construed
as one from the current syntax. In most cases people have features that
supply some function generically and then as an implementation detail have
some platform-specific plugins. In that case you are better off using the
<plugin> markup for os, ws and arch (see the RCP feature for an exampel).

Jeff

James D Miles <jdmiles@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

11/08/2005 06:25 PM

Please respond to
"Eclipse Platform Update component developers list."

To	platform-update-dev@xxxxxxxxxxx
cc
Subject	[platform-update-dev] Filters for eUpdate

It is not clear to me that we have adequate filters for features.
We have 
os = {win32, linux, aix, solaris, hpux, qnx, macosx, unknown} 
arch = {x86, PA_RISC, ppc, sparc, x86-64, ARCH_X86_64, ia64, ia64-32}
ws = {win32, motif, gtk, photon, carbon, unknown}

What would be the preferred way to prevent eUpdate from attempting to load
a feature that expects a full blown platform. Chances are good that the
required features or plugins would not be satisfied but that will give
an error. Shouldn't we have a filter to handle this?_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev