Re: [platform-update-dev] Product Requirements for Update Manager

[Peter Manahan <manahan@xxxxxxxxxx>]

platform-update-dev-admin@xxxxxxxxxxx wrote on 08/12/2003
04:58:01 PM:

>
> 
> We all agree here, and to make sure we are addressing the right 
> issues, it'll be good if you can list some of the things you are 
> perceiving as particularly "messy". 
> To me, the startup/reconciler protocol (restarting of eclipse with
a
> reconciler app, etc.) is a good candidate. Another one is the nested
> features with various version matching levels. 
> 
We do specific install work to not have the reconciler
get called. Always have problems when the core.boot plugin isn't updated
along with the update plugins as well. Be nice not to use it.

Nested features would be nice to not have. They handle
update control (where allowable updates are from) and we use them for packaging.
I believe the matching was placed to handle some update problems when only
a few fatures change or for patches.

If they are removed they would become more like manifests.
The problem with that is then there is no way to tag a feature as a unit
of function.  

For example. Currently org.eclipse.jdt in WSAD is
contained in WSAD's root feature. An install wishing to extend WSAD can
query WSAD's eclipse for a list of features and plugins (there is an undocumented
application for this which probably should get documented ). The install
just looks for org.eclipse.jdt and knows that the JDT is installed.  With
a feature as manifest then WSAD's root feature would just contain all the
plugins. The install would have to verify that every plugin it requires
in the JDT is there. Just a little more complicated.

> > 


> >One good case for the user 
> > being able to change this policy is the ability to redirect the
> >          default update site to an internal
server within an  
> > organization by their IT dept. 
> 
> Is there anything over what is currently implement in 3.0 (with site
> redirection via preferences) ? 
> 

Should be ok. As long as the policy (I am assuming
there is going to be a policy file?) states that only the WSAD feature
can be used for the update of the plugins. Have to go through some use
cases on it. My main concern is pointing WSAD at eclipse.org's site via
this mechanism. I would not want the eclipse plugins in WSAD updated in
that case. 

> 
> We are investigating exposing of platform.cfg in a "new and 
> improved" public format, and expect that each product will provide
> one to start with. This platform.cfg (likely platform.xml) could 
> define the sites and the associated install policy. 

I'd like to have to use the eclipse API's to modify
this though. Having it be modified via API would help keep it valid.

> 
> >         
> > 2. Runtime resolution 

> 
> There has been some discussions about predefined configurations and
> "profiles" support. Unlike the ui roles, this is about scoping
the 
> features that will run. 

The removal of nested features may cause some nastiness
here. If features move from what they are currently to a manifest then
they shouldn't be involved in the runtime at all. Unless the features "own"
plugins they aren't any good for policy (unless the policy is specified
somehow indirectly). So I expect it won't be scoping features that run
but instead plugins/bundles that run. Or a combination of both. I need
to think about it some more :-)

> 
> >             c) Need to be able
to link multiple products together to
> > form one product. 
> >                 This
partially relates to bug https://bugs.eclipse.
> > org/bugs/show_bug.cgi?id=35037. 
> 
> Care must be taken so your point a) above won't be invalidated. 
> 

Yep.

> > 3.  Build 
> >         How it works today: WSxx tools have
approximately 100 
> > features and 600 plugins including nl and documentation ones.
> 
> Only that many?  :-) 

:-) I forgot to add the nl even though I said I did.
 Count with NL is 157 features and 1014 plugins.



> >  4.Install 
> >        a)  We need the ability in the
features to point to arbitrary
> > datafiles/jars/licenses. Currently you can do this with plugins
via 
> > the archive flag. 
> >             We'd like to be able
to do it for data. The scenario 
> > occurs when you need to update multiple products with the same
non-eclipse 
> >             portion for example
a runtime. We'd like to only have 
> > one version of the runtime hosted as they can be quite large.
> 
> Good point. 
> 
> >        b)  Command line invocation of
update manager function. You 
> > should be able to call eclipse to update from the 
> >             commandline via a native
installer. This requires 
> > feedback from eclipse on how its doing and what failure or successoccurred.
> 
> Give it a try with the current support in eclipse, and let us know
> what needs to be improved. This is new function, so any feedback is
> appreciated. For example, how do you expect licence approval should
> work in this scenario? Are these commands sufficient, any serious
> bugs/limitations? 
> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-
> update-home/doc/working/documentation/standalone_update.html 
> 

Will do.

> 
> >        c) Multiple install handler definitions
- we are finding 
> 
> Worth looking into, but I think the enablement is there (as you 
> said, you can implement chaining), so I'd consider this a lower priority
item.
> 
Yep its a nice to have.

> >       d) One license. Currently we need to ship
2  licenses for 
> > every feature we wish to install. If we could remove the need
for a 
> > text license 
> >            that would make life
sooooo much easier. 
> 
> With the current browser support in eclipse, I think the text 
> version won't be needed anymore. 

Cool.

> 
> >        e) Query update manager. A native
installer likes to check to
> > see if anything will break if they uninstall. We like to present
the
> > user with the option 
> >             If we could as the
update manager if there was any 
> > problem when removing x features and prompt the user with 
> > consequences it would be 
> >             nicer than  just
barfing when eclipse comes back up :-) 
> 
> Check the current standalone commands (see above url), there is flag
> for just testing the operation. Is this good enough? 
> 

Will let you know with a bugzilla if it isn't :-)

> > 
> > 5  Usability 
> >       a)  Require that we be able to rollback
a fix. 
> 
> We also plan to simplify the patching story a bit, so we expect this
> to work much better. 
Ok am looking forward to it.


> >         c) Download Speed - anything to increase
this. 
> 
> I'd translate this in shorter download time. Even with same (slow)
> speed, the less stuff to download, the better. There is some basic
> level of partial plugin support, but the granularity is at file 
> level, not at file content level. In 3.0 it is possible to update
a 
> plugin by providing only the files that have changed. We are looking
> at 3rd party tools or implementing support for dealing with deltas
> at a more granular level, such as files in a zip/jar. 

Yes the delta plugin support will work extremly well
for updates to plugins and feature that already exist. This is for the
case where that function is discovered and downloaded. The large runtime
data files is where download time becomes critical though. These things
can be as large as 500 MB.


Peter