Re: [platform-update-dev] Install/Update API

[Peter Manahan <manahan@xxxxxxxxxx>]

Injected a couple comments <pm>.
Notes doesn't indent replies properly.

Peter

Bob Foster <bob@xxxxxxxxxx>
Sent by: platform-update-dev-admin@xxxxxxxxxxx

01/12/2003 10:11 AM

Please respond to
platform-update-dev

To	platform-update-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-update-dev] Install/Update API

Peter Manahan wrote:
> How would you be able to tell if the install was shared?  I don't
think 
> you can,  even if there was a way then don't think you can expect
the 
> Update Manager to help enforce license requirements. The user must
> accept the license before installing. If the user does so and it is
a 
> single person license then it is the user's responsibility. If there
a 
> need to prevent more than one user running then the plugin needs to
use 
> a license manager to handle that.

I believe if you read the posting I replied to, it was a use case (one
of the many) requesting explicit support for shared and site-managed 
updates.

<pm>
     We are working off of different
assumptions.

     If you read it with the assumption
that eclipse is single user based the
     conclusion you could come to was
that there was special work required to "turn on"
     sharing. 

     If you assumed, as I do, that
eclipse is a shared installation already then 
     what that post describes are flaws
in its implementation. Since it already
     is a shared installation the request
for detection of shared installation 
     for "single user" license
a license enforcement issue.
</pm>

Your reply falls in the category "If you can't
do a perfect job, don't 
do anything at all." 

<pm> 
      You've misinterpreted it. It
falls into the category of 
      "You can't do a perfect
job. So do enough to stop legitimate users 
     from becoming accidental pirates."

</pm>

I am not interested in the Update Manager enforcing
license requirements. If some future version of Update Manager knows it
is doing a shared installation, then it can easily provide a hook for 
features that object to a shared installation to notify the user. That
seems like a modest enough request.

<pm>
     I think we are assuming different
things about what an eclipse 
     single user installation is.

     My view and that of the products
I work on which use eclipse is that
     every installation is a shared
installation. A single user installation is
     a shared installation with one
user.

     So the request for detecting a
shared installation didn't make any 
     sense except for license enforcement.

     You may want to look at an install
handler which allows you to hook
     into the install of the features.
We use it to check for prerequisites and
     to give a user an error if those
fail. 
     
</pm>

Piracy, in general, has little to do with open source. The only piracy
prevention that works is a society in which property rights are 
enforced. In such a society, a "cursory check to prevent inadvertent
piracy" is a useful and practical tool.

<pm>
     The point I was attempting to
make and obviously failed at was that because
     eclipse is open source any attempt
to embed strict security checking there is
     wasted effort. 

     The license acceptance update
manager already provides falls into the 
    "cursory check" category already.
</pm>

Bob Foster

> 
> We've looked at the piracy before and it shows one of the open source
> holes. There is no way to prevent piracy when the base platform you
are 
> sitting on provides the source to work around any security it may
> provide. Even if update manager attempted to prevent this a patch
could 
> be made available to update manager (a completely legal patch) that
> worked around the issue.  Additionally there is nothing preventing
a 
> user from downloading the jar's themselves and applying them to eclipse
> manually its fairly easy to do so.
> 
> So what you are left with besides a bad taste is the ability to do
a 
> cursory check to prevent inadvertent piracy. The real pirates will
walk 
> around the check quite easily anyway.
> 
> 
> 
> Thanks,
> 
> -----------------------------------
> Peter Manahan
> WebSphere Tools
> Build/Install and
> Product Architecture
> ------------------------------------
> manahan@xxxxxxxxxx
> 
> 
> *"Bob Foster" <bob@xxxxxxxxxx>*
> Sent by: platform-update-dev-admin@xxxxxxxxxxx
> 
> 01/12/2003 08:03 AM
> Please respond to
> platform-update-dev
> 
> 
>                  
> To
>                  <platform-update-dev@xxxxxxxxxxx>
> cc
>                  
> Subject
>                  Re:
[platform-update-dev] Install/Update API
> 
> 
>                  
> 
> 
> 
> 
> 
> Long latency on this, I know, but I hope some consideration is given
to
> allowing plug-ins to selectively "opt out" of shared installs
when the
> plug-in license only covers single-person use. A plugin should/must
be able
> to require that it not be installed in a shared eclipse unless its
license
> permits. IOW, the update feature should not facilitate piracy.
> 
> Bob Foster
> 
> ----- Original Message -----
> From: "Mark Kralj-Taylor" <mark.kralj-taylor@xxxxxxxxx>
> To: <platform-update-dev@xxxxxxxxxxx>
> Sent: Thursday, October 16, 2003 3:05 AM
> Subject: Re: [platform-update-dev] Install/Update API
> 
> 
> Message
> I needed to code against the Eclipse 2.1 update API to facilitate
deployment
> of Eclipse, WSAD and a mix of open source and in-house extension
> features/plugins to a read-only file system accessed by Widows, Linux
and
> Solaris desktops.
> Before writing this code I exchanged some emails with the
> platform-update-dev mail group (answered by Christophe Eleck).
> 
> We are really hoping that Eclipse 3.0 will avoid the need for our
code
> entirely, so this sounds a good point to explain our use case again:
> - To reduce deployment and maintenance costs we avoid local installs.
> - Instead we provide applications like Java and Eclipse on a global,
> READ-ONLY file system.
> - Users do not install Eclipse on their local machine, nor do we want
users
> to download features from an update site.
> - We want to provide everything centrally.
> - To deploy an application we first package it to a read-write 'dev'
area,
> it is then turned-over to the read-only 'dist' area.
> So there is a difference in path prefixes between where an application
is
> packaged, and where it is run from. It is important to us that this
doesn't
> cause problems for the 'eclipse -install' process (e.g. storing full
paths
> in platform meta-data)
> - Each user has their own read-write Eclipse workspace directory under
their
> home directory.
> 
> The Eclipse update mechanism is important to us because it lets users
pick
> which extra features they opt-into, in 'their' Eclipse experience.
> 
> To make the Eclipse update mechanism work in our read-only 'dist'
> environment, I added an 'Add local extension install site' action
to the
> 'Eclipse Platform' object in the 'Install Configuration' tree view.
This
> lets you add a pre-existing extension directory.
> 
> Eclipse 2.1 has several extension site types, tagged by dot files.
I found
> that an update manager site, tagged with a '.eclipseUM' file worked
best.
> However because the update manager checks that .eclipseUM update sites
are
> writeable, I had to cut-paste-modify code, rather than simply call
the
> update manager API.
> 
> For the user it is a 2 step process to use a feature from a read-only
> extension install site:
> 1) add read-only extension install site
> 2) enable desired feature(s) from the extension install site
>       (remembering to press the 'show disabled features'
button first)
> 
> There is a problem with our approach. Where we have provided several
> features in one extension install site, intending that users can
> enable/disable features within the site independently. After restarting
> Eclipse all features from the extension site can be enabled, not just
the
> ones the the user actually selected.
> 
> I hope Eclipse 3.0 will provide better support for shared installs
of
> Eclipse, so we don't need the code I have attached.
> Specifically:
> - Continued support for shared install of Eclipse in a read-only
> file-system.
>     (with no absolute paths embedded in any platform meta-data,
so we can
> copy from 'dev' to 'dist' areas)
> - Support for users adding (importing) shared extension sites from
a
> read-only file system (without copying).
> - Externalising platform configuration  information, to a user
> visible/editable/copyable XML file in user's Eclipse workspace. This
file
> would include what extension sites the user has added and which features
> from them are enabled.
> (we find that Eclipse workspace can get corrupted, and some want multiple
> workspaces, in both cases want to minimise time taken to duplicate
a
> workspace setup)
> -- Other information could be provided in human readable/editable
files in
> workspace dir:
>  - locations of project directories
>  - eclipse startup and JVM options - handled by Eclipse boot
launcher
> executable, this would be more user friendly than using long command
line.
>  - how long would it take to auto export .epf preferences on
a clean
> shutdown, so if workspace gets corrupt, a user always has a recent
copy to
> restore preferences from?
> 
> Mark.
> 
>        [platform-update-dev] Install/Update API
> 
>    a.. From: Dejan Glozic <dejan@xxxxxxxxxx>
>    b.. Date: Mon, 6 Oct 2003 16:24:56 -0400
>    c.. Delivered-to: platform-update-dev@xxxxxxxxxxx
> 
> ----------------------------------------------------------------------------
> --
> 
> 
> Poll:
> 
> The Eclipse Install/Update team would like to know of any and all
cases
> where the current (2.1) Update API is used. Note that we are only
> interested in programmatic uses (i.e. referencing any of the non-internal
> classes in org.eclipse.update.core plug-in) and not actually using
features
> and/or update sites.
> 
> Please send your answers to platform-update-dev mailing list only.
> 
> Regards,
> 
> Dejan Glozic, Ph.D.
> Manager, Eclipse Platform Components
> D2/MY7/8200/MKM
> IBM Canada Ltd.
> Tel. 905 413-2745  T/L 969-2745
> Fax. 905 413-4854


_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev