On 02/02/2008, Jean-Sebastien Delfino <[EMAIL PROTECTED]> 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? >
I know nothing about Spring or Tuscany, so take these comments as you wish. It's not clear to me if Webflow is a part of Framework or independent - does one have to download both? Similarly for the other products/addons on the page. There is a long list of Homepages at the bottom - why do only some of them have download sections on this page? I find the packaging of the Framework a bit annoying. Suppose I downloaded the binary only, and then decide I need the documentation - I've got to download the binary as well. Likewise if I just want the documentation. Why not just provide the documentation separately? BTW, the heading "For More Information Access Spring Project Homepages" could be clearer, e.g. For more information on Spring projects, please visit their homepages > [1] http://www.springframework.org/download > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
