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

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

The problem is real but the solution
is not to write a new kind of update site etc.  There is nothing wrong
(IMHO) with having different physical sites for different users or kinds
of users.  There are many things you can do on the server side if
you are willing to run code there.  Characterizations or classifications
of features is an interesting direction.  There are some issues with
defining canonical categories etc but it might well be worth investigating.
 As with many things it is harder but more interesting to think of
a general scheme than to do a particular solution for this one case.

wrt broken features...  Features
are only broken wrt to particular configuration.  It seems reasonable
to hide the list of broken features for a particular configuration.  These
are ones whose dependencies cannot be met or whose plugins cannot be installed.
 Perhaps this eliminates the offending features right there?

Jeff

p.s., have you seen the Eclipes-PlatformFilter:
 bundle manifest header ?

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

11/16/2005 12:22 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

I have no problem with your points. So how do we solve
this?

case 0: plugins that are common are osgi, runtime and update.configurator

case 1: 
RCP apps that have requires for SWT, JFACE, workbench, and others will
be broken. That is because the plugins have been renamed in eRCP because
they are not equivalent. 

case 2: 
eRCP plugins that want to be usable on RCP platform do not use the the
requires for plugins(other than the common case 0 plugins) but uses the
import packages list. If they use eSWT and Mobile extensions then RCP will
need the Mobile extensions plugin. 

Assuming we have a common site
- We don't want to present a long list of broken features (RCP features)
to a user in update.ui
- I don't think we should always suppress the list of broken features.
It may have been intended for eRCP install.

Dorian
Birsan <birsan@xxxxxxxxxx>

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

11/16/2005 09:02 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

All good points. 
Just for completeness: the site "type" indicates an extension
providing the ISite object that will be used to access the content of the
site. There are no other semantics associated with it.
This also points to a limitation: that extension must already exist in
the current install; currently there is no way to pick up an arbitrary
site type handler (also goodness, considering security concerns).

-Dorian

The real danger is not that computers will begin to think like men, but
that men will begin to think like computers. - Sydney J. Harris

Jeff McAffer/Ottawa/IBM@IBMCA
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

11/16/2005 09:20 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'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
_______________________________________________
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