| Tim,
Your ideas are definitively interesting and worth a discussion. However, it feels a little strange that you assume that we created a prototype that will limit us in the future - and that even without thinking about the problem first.
On the wiki page and in previous emails you are presenting the solution of a shopping cart. This is fine, and I don't see a problem with combining a shopping cart in the future with what we have started implementing. But I think that the problems listed can also be solved with epp and the new dynamic package delivery, check my edits on the wiki.
Right now I would prefer to keep the scope of the new epp component as it is and in sync with what the epp project is doing. After we have taken the first step and made it a success we can either think about expanding the scope or even start a completely new project addressing a set of new ideas. From my experience it makes a lot of sense to showcase something real as early as possible in the project life cycle and gather feedback. This is not about ignoring the community, rather providing something real to the community and improve it based on real world feedback.
If you feel that a php frontend for the wizard would be a simpler and better solution you are happily invited to go and implement the functionality in php.
Thanks,
Jochen Am 14.07.2008 um 19:20 schrieb Timothy Webb: Mark, Great question! To help get the ball rolling on understanding the problem, I've created a new Wiki page with some initial thoughts and where we can level-set our collective understanding of the issues at hand. http://wiki.eclipse.org/Eclipse.org_Downloads_AccessibilityDoes this work for you / the group at large? Tim On Jul 14, 2008, at 11:18 AM, Mark Russell wrote: Tim: I like what you are saying. What is the best way to go forward with your idea? Timothy Webb wrote: Jeff,
I agree that the more general improvements of Eclipse.org are out of scope for EPP. This was the main reason I had suggested and still support splitting out the work for Eclipse.org from the EPP project. In looking at the genesis of this idea, there was the concern about the ease for end-users to download and access software from Eclipse.org. As there are two entry points to this problem, users looking to download Eclipse and have us offer add-ons, and users that want to try out a particular technology, I believe we should step back and evaluate the different needs before jumping into a specific technical solution.
Problem 1:
- User wants to download Eclipse and we'd like to offer optional components
Problem 2:
- User wants to download Eclipse technology X and we'd like to make that easy
I recognize there may be some existing work in a RAP-based EPP Wizard prototype that could help in part of this implementation and I am suggesting before we start limiting what we can potentially do based on a particular prototype, that we understand the larger problem first. Once we understand the context of what we need to solve, finding an efficient and quick way to solve the problem will be simpler -- whether it's via some simple PHP code for a light weight solution or choosing to build on the EPP Wizard as you've proposed.
Tim
On Jul 14, 2008, at 9:12 AM, Jeff McAffer wrote:
AFAIK, not much has happened on the EPP wizard since the original posts etc. We should restart this work in the near future.
Tim, your scenario is interesting. In my mind right now however it is beyond the scope of what we are trying to do in EPP. EPP is about the packaging and, in a sense, the initial discovery and acquisition of the packages. The server side element of this (actually the whole thing) is intended to be quite light. The sort of thing you describe may be enable by dragging and dropping "IU URLs" from the web to some p2 facility for example.
Jeff
Timothy Webb wrote:
Jochen,
Thank you for the detailed response. It sounds as if we are looking at similar aspects of the same problem and I agree with the areas you've listed though I do believe there is one more case that can be solved at the same time with about the same work level.
The two key areas you listed were:
- offer the possibility to alter the predefined packages on the fly
with other content from the Ganymede update site based on a simple to
use web based wizard
- provide a mechanism to forward a users selection of plugins to a
commercial site that is offering additional components
Another important area is:
- offer the ability to download a project's software from the project page and feed into a dynamic download flow like you discuss (aka a shopping cart model)
The problematic model I was looking at is:
1. User googles some interesting technology they read about, say EclipseLink
2. User clicks the Download page of EclipseLink
3. User is presented with a 5 MB zip file and no easy way to get started with it
4 and on. A bunch of steps involving finding how to add it to Eclipse, extracting, etc.
An optimized model would be:
1. User googles EclipseLink
2. User goes to Download and clicks an Add to My Download button
3. A shopping cart summary shows on the right side of the page
4. User clicks Download in the shopping cart (or wants another project and repeats 1-3)
5. Download Page walks user through wizard for retrieving software with other base profile, or linking over to partner site
Whether the "shopping cart" is built before or after choosing a base profile, the base concept is the same -- that users need the ability to easily select the components that they want to install. My concern with the wizard after the fact, while necessary for some users, is that many people don't want to walk through a complex flow to find EclipseLink, instead, they google, take the first hit, and then want to get started. Whether a project's page lists an update site or a Zip file (or both), getting that up and going in an Eclipse install can be anything but an easy project.
Thoughts?
Separately, have you had an opportunity to consider some of the other questions I raised previously? Also, would you mind providing an update on the status of the work and where/how to get involved?
Thanks,
Tim
On Jul 1, 2008, at 4:44 AM, Jochen Krause wrote:
Hi Tim,
Sorry for taking so long to answer, but Ganymede kept us very busy and
the work on this stuff was paused.
We are certainly open to discuss where this is heading. Before
commenting on your points I would like to describe once more the key
drivers and intentions for this project.
At the moment we do not have any integration between open source
software from Eclipse and commercial offerings from the larger
Eco-System. This is unfortunate, as it both does not serve our end users
nor our commercial community. It is however not easy to provide
mechanism for achieving a better integration that meets all of our
constraints: Eclipse can not be in the distribution business (for legal
and ecosystem reasons) - Eclipse can not distribute commercial
offerings, we don't want to "threaten" our end users with too much
commercialisation, we want to provide a better our of the box experience
for Eclipse, which means that you need to be able to combine the things
you need.
The joined releases and EPP with the standard packages have improved the
situation for the open source side, and we are now planning to build on
top of that. We have two things on our mind:
- offer the possibility to alter the predefined packages on the fly
with other content from the Ganymede update site based on a simple to
use web based wizard
- provide a mechanism to forward a users selection of plugins to a
commercial site that is offering additional components
Two brief examples:
You select the Java development package as your starting point and add
C/C++ to it. Then you either download the p2 installer that downloads
your selection or you start the p2 installer with webstart.
After having selected the Java development package and added Datatools
you get to the page where you can start the download, but you see an
"advertisement" that catches your eye for adding MySQL to your download.
You click the advertisement and get to the vendors site. The vendor
receives your plugin selection and can offer the user to add more stuff
to his download. The vendor will provide the ultimate download,
hopefully taking advantage of p2.
Does that make the picture clearer?
Jochen
-----Original Message-----
From: Tim Webb [mailto:trwebb@xxxxxxxxx] On Behalf Of Timothy Webb
Sent: Wednesday, June 04, 2008 9:43 PM
To: mitch.sonies@xxxxxxxxxxxxxx; jeff@xxxxxxxxx; Markus Knauer; Jochen
Krause
Cc: Eclipse Management Organization; epp-dev@xxxxxxxxxxx
Subject: Re: [eclipse.org-committers] Eclipse project announcement
Markus, Jochen, Jeff & Mitch,
Congratulations on stepping forward to create a new work area focusing
on enhancing the configuration, download and installation experience for
Eclipse technology users.
As I read this email, I can imagine a new widget available on all of the
Eclipse project pages that works like a shopping cart ("Add TPTP
Profiling to cart"). When you are done choosing interesting software,
you can then click a Finish button in the cart summary which would allow
downloading the software from Eclipse.org directly or hand-off to any
participating ecosystem partner for further configuration and download.
Whatever the ultimate solution, I'm excited about us having a
lightweight, scalable add-on to the current Eclipse portal which
provides great value to end users of Eclipse technology and flows within
the existing site's usage patterns.
Stepping back, I see two areas of work potentially described -- one is
the creation of an exemplary implementation and extensible platform
created to solve the generic provisioning problem of choosing from lots
of Eclipse software accessible from the web in general. This first bit
of work is analogous to a multi-site "shopping cart" for Eclipse
software. Secondly, I see a area which is the selection of a solution
that helps address the specific problems of Eclipse.org which might have
a different objective and may or may not use the same solution. While
these areas are related, I see them as distinct problems for which
multiple solutions are possible.
Given the visibility and importance of changes to Eclipse.org, I would
like to propose we separate out the Eclipse.org technology solution and
create a new technology project that will focus on delivering a near
term solution for the current download complexities at Eclipse. As
could be inferred from the EPP component proposal, the solution would
likely leverage a p2-based installer with web integration into the
existing Eclipse portal and provide a way for users to more easily
access software whether by using a direct downloaded installer from
Eclipse.org or choosing to switch over to a partner site as proposed for
the new EPP component.
We are also excited about becoming actively involved to help with this
effort.
Congrats!
Tim
On Jun 2, 2008, at 7:44 PM, Anne Jacko wrote:
The Eclipse Packaging Project (EPP) is announcing a new
component -- please see below. Thanks.
------------------------------------------------------------------------
------------------------------------
The dynamic package delivery component provides an extensible
framework for,
and an exemplary implementation of, a service for dynamically
selecting and
downloading/installing installable units.
This component will be extensible and open in that it will
enable multiple
websites to participate in the user selection of installable
units (in
sequential order, i.e., the selections from one site are
forwarded to the
next and so on until the user chooses to download and install
the selection).
The Eclipse Foundation intends to use the exemplary
implementation at
eclipse.org to create a better user and member experience for
downloads.
Markus Knauer
Jochen Krause
Jeff McAffer
Mitch Sonies
------------------------------------------------------------------------
------------------------------------
Anne Jacko
emo@xxxxxxxxxxx
_______________________________________________
eclipse.org-committers mailing list
eclipse.org-committers@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-committers
IMPORTANT: Membership in this list is generated by processes
internal to the Eclipse Foundation. To be permanently removed from this
list, you must contact emo@xxxxxxxxxxx to request removal.
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev
-- Mark Russell Instantiations, Inc. +1 724-368-3331 (land line) http://www.instantiations.com_______________________________________________ epp-dev mailing list epp-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/epp-dev
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev
|
