Jean-Sebastien,
Let's chat some more about objectives, to see why we're seeming to look
at this differently:
Jean-Sebastien Delfino wrote:
Mike Edwards wrote:
[snip]
>> Jean-Sebastien Delfino wrote:
I think we could improve our distro scheme to provide:
- smaller packages
- easier for people to find what they need
I agree with the objectives. The second of the two is more important
from my perspective.
I was thinking about the following binary distro zips:
- tuscany-core.zip - The base that everybody needs.
core assembly model and runtime
Java APIs, Java components
- tuscany-web.zip - For WS and Web developers
WS binding, Web 2.0 bindings, Scripting components, Widget components
- tuscany-jee.zip - For JEE app integration
EJB, RMI and JMS bindings, Spring components
- tuscany-process.zip - For process development
BPEL and XQuery components
- tuscany-all.zip - all of the above
I'm not convinced that this is a particularly useful split. Sorry to
disagree, but it is worth debating this before folk do a lot of work.
From the perspective of an end-user, their main goal in life is to
get their applications working on their runtime.
I view this as something like:
- give me a Tuscany package (containing the Tuscany runtime materials)
and a way of installing that with my runtime. Then tell me how and
where I put my application stuff so that it will run.
- splitting up the Tuscany package into several packages does not seem
to help me very much. Now I have to go read and understand what each
package does and what I need to do with it.
- let's envisage a series of potential runtimes which I could be using:
a) standalone Tuscany
b) Tomcat
c) Geronimo
d) WebSphere
e) a. n. other runtime
What I think I'd really like is to be told
1) go get this (one) download package containing the runtime
2) have an install script of some kind that knows how to take content
from the download package and put it "in the right place(s)" for it to
be usable with my runtime (may be one script per runtime type)
- the partitioning which Jean-Sebastien describes above is actually
more appropriately done by the install script. It will either KNOW
that only certain pieces are appropriate for a given runtime (eg no
point in installing JEE related stuff on a non-JEE runtime), or it
will be able to ask some simple questions about whether I will need
some of the less common pieces
- am I asking for too much here, or is this the best approach for the
end users?
Sorry, I'm not convinced:
- The packages I've proposed are relevant to all the runtimes you've
listed (including the JEE one).
- If I'm an application developer or a system administrator and I'm not
able to say if I'm going to use Web 2.0, JEE integration or business
processes, I won't be able to answer the install script questions either.
I find the organization of the Spring framework download page [1] clear
and useful and I was envisioning a similar download page organization
for Tuscany. Do people find it confusing and can they say why?
[1] http://www.springframework.org/download
The problem I have with the Spring download page, which I think is the
same as the reason I'm not keen on the split you've suggested above, is
that I first have to get to grips with what each download is about.
So, if I'm a newbie to Spring, I first have to learn about "Web Flow",
"Security", "Web Services" and so on, in order to know whether I need
them or not. For someone already familiar with Spring, this split might
be OK. For a newbie, it isn't.
Let's go back to the reason to want to split things up. We've
previously discussed:
- splitting to make the download smaller
- making it easier for people to find what they need
I've said before that I think making things easier for people should be
the more important of the goals. The trouble is that these requirements
are actually in conflict. The simplest package is a single package that
I download and then run as an installer - and I get everything I want.
No more searching. No sudden discovery that something does not work
because I don't have some needed dependency.
I agree that package size is important, but it is less important to me
than making things easy. Even 100Mb ain't too big a deal these days
with Broadband a general commodity. (Microsoft certainly seem to think
so when you look at some of their update bundles !!).
I note Simon Nash's comment about the potential of a small download
package that has some installer that then goes and fetches the rest.
This is a bit like the Eclipse approach. I could live with that - as
long as it's also possible to get a big bundle that I can download for
any offline work.
If we don't think that folk can answer questions - and you may be right
on that - then best to assume they need everything and avoid problems
that way.
Hope this helps,
Yours, Mike.
PS I definitely agree with the idea of having a "runtime" bundle
separated from a "demos and samples" bundle.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
