[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] New Update Manager UI : Your thoughts
|
Just to clarify a little. At the
provisioning workshop we discussed the idea of a "governor" who
would essentially inject these policy choices into the director. We
actaully don't want alot of people running around implementing their own
directors if it can be avoided. The director is likely hard/complicated.
While we can supply "director building blocks", that introduces
another level of API/SPI. In any event, the director should be pluggable
yes.
Jeff
Peter Manahan/Toronto/IBM@IBMCA
Sent by: equinox-dev-bounces@xxxxxxxxxxx
06/13/2007 02:57 PM
|
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> |
|
|
To
| Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| Re: [equinox-dev] New Update Manager
UI : Your thoughts |
|
I think we are mixing up two aspects of the provisioning work. The mechanisms
for actually performing the provisioning (doing the real work) and the
mechanisms for defining policy around provisioning (i.e. when and what
to provision). Since as far as I know the provisioning work is supposed
define a pluggable "director" aka the policy decider, there
can be multiple implementations of policy makes. Some implementations may
decide to enforce a strict license check and some can decide not to. I
fully expect to have to roll my own director rather than use the default
equinox implementation of it. There are probably too many different use
cases to try and roll a single implementation that covers them all.
The original thought behind all this was a new Update Manager UI.
In the original thread I made this comment
"So it would be useful to understand/define the intended role of the
new update manager UI as well before going down the same path it went previously"
The role of the Update Manager UI on the new provisioning code obviously
hasn't been defined. What policies will new Update Manager implement? I'd
suggest that it should start with the requirements needed by eclipse.org
to provision eclipse.org content like Europa etc.
Peter
equinox-dev-bounces@xxxxxxxxxxx wrote on 06/13/2007 02:28:26 PM:
> OK, lets step back and look at it differently.
>
> I don’t think this would be illegal, but I am not a lawyer, and I
> don’t play one on TV.
>
> Infor (the company writing the software) is using equinox server-
> side to assemble an ERP system at WidgetCo, the company that
> manufactures widgets.
>
> This is not an eclipse IDE of any kind.
>
> WidgetCo and Infor have a licensing agreement between them. WidgetCo
> has purchased a license for Infor’s software and can receive free
> updates for 1 year from the purchase date. Now, instead of
> automatically accepting license agreements, we have a more complex
> requirement, but a real one that needs a solution.
>
> Possible options:
>
> 1. There are update sites that are always trusted by the update
> manager. The user that sets the “I trust this update site” flag
must
> have in essence agreed to the license in advance. Such as free
> updates for a year as per a license agreement. In this case, Infor
> will stop populating the WidgetCo update site with new versions
> after a certain date, and the onus is on Infor to make this happen.
> Probably by getting a new license agreement signed. Very little
> needs to be done in the update manager in this case, except to trust
> sites that are marked as trusted. Notes could be added as to why it
> is trusted, perhaps.
>
> 2. The update sites in the update manager could have attached
> multiple license keys. These keys are transmitted to the update site
> with the update request. Now the update site is not a simple set of
> web pages and resources served by a apache. It needs to be a web
> application that can validate the license keys. The update site
> either sends the updates or rejects the request.
>
> 3. The update site provided by Infor could be behind a password
> protected URL. Access to this URL is only given to customers that
> have a signed license agreement. The license requirements are all
> handled outside of the scope of the update manager. The the update
> manager, the update site is marked as trusted.
>
> 4. Infor provides a password protected URL from which WidgetCo can
> download an update site that WidgetCo can host locally. Again, Infor
> and WidgetCo have the license agreement managed outside of the scope
> of the update manager. This downloaded and hosted update site is
> marked as trusted.
>
> In all cases, the marking of an update site as trusted means that
> all license management is being handled outside of the update
> manager. And the act of marking an update site as trusted means that
> the administrator has agreed that all licenses required at that site
> are already handled outside of update manager.
>
> An update site should have the ability to override this and say:
> “Never allow update manager to trust me”. This could even be the
default.
>
> Without introducing a full blown license management system, we
> cannot get too complex in the requirements here. But server-side
> implementations will require the ability to trust some update sites
> and not need license agreements individually agreed to. If only
> because sometimes there will be no human and no UI present when the
> update happens.
>
> -Don
>
>
> Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307
|
> mobile: 416-543-1085 | don.laidlaw@xxxxxxxxx
>
> On 6/13/07 11:56 AM, "Brett Wooldridge" <bwooldridge@xxxxxxxxxxxxxx>
wrote:
> I think there are legal ramifications, at least in the United States
> for that. While we’re all annoyed by licenses, I don’t think
you
> can “auto-dismiss them” any more than you can stamp your car loan
> with your signature.
>
> -Brett
>
> On 6/13/07 8:59 AM, "Laidlaw, Don" <don.laidlaw@xxxxxxxxx>
wrote:
>
> True, but it can also be a policy of a plugin consumer to accept the
> licenses of trusted update sites. Then the consumer only has to
> determine which update sites will always be trusted.
>
> In using equinox on the server side, the update sites will usually
> be in the same company.
>
> -Don
>
> Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307
|
> mobile: 416-543-1085 | don.laidlaw@xxxxxxxxx
>
> On 6/13/07 9:55 AM, "Peter Manahan" <manahan@xxxxxxxxxx>
wrote:
>
> The need for license acceptance is typically a requirement
> discretion of the plugin provider and not the consumer of the
> plugins. So allowing the consumer to disable the license acceptance
> should only be optional at the discretion of the plugin provider.
>
> Peter
>
> equinox-dev-bounces@xxxxxxxxxxx wrote on 06/13/2007 09:04:39 AM:
>
> >
> > The provisioning system should already know about the sites and
> > should be able to discover more.
> >
> > Actually I missed in there where the users said which plugin
they wanted.
> >
> > User should not have to accept a license if the plugin is coming
> > from a known/trusted site. Sites should be ranked in this
way
> >
> > Restart may not be needed
> >
> > Jeff
> >
> >
>
> >
> > "Prashant Deva" <prashant.deva@xxxxxxxxx>
> > Sent by: equinox-dev-bounces@xxxxxxxxxxx
> > 06/12/2007 08:26 PM
> >
> > Please respond to
> > Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> >
> > To
> >
> > "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
> >
> > cc
> >
> > Subject
> >
> > Re: [equinox-dev] New Update Manager UI : Your thoughts
> >
> >
> >
> >
> > Ok, here is some thoughts on the gui for installing a new plugin.
> > This is in keeping with the philosophy of keeping the simple
things simple.
> > I wish there were a place where I could upload some docs and
sample
> > images to make the point more clear, but i will just type some
> stufffor now.
> >
> > 1. User clicks on 'Install new plugin'
button
> > 2. Dialog box with single text field
asks to enter the url of
> > pluign update site.
> > 3. update manager automatically gets
the latest available
> > version of the plugin.
> > 4. asks the user to accept the license.
> > 5. if license accepted, then installs
plugin and asks user
> torestart.
> >
> > The update site url, etc are automatically saved by the program
and
> > user doesnt need to give a 'name' along with the url as we have
to do now.
> > Also no dialog box for confirming 'install all'. All user has
to
> > enter is the url and accept the license.
> >
> > the dialog in step 2 can have an 'advanced' button, which when
> > selected allows user to choose the exact version to install.
> >
> > your thoughts? any compulsory steps in the install process we
might
> > be missing this way?
> >
> > prashant_______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Attachment:
smime.p7s
Description: Binary data
