At 06:13 AM 3/24/2003, you wrote:
Niclas Hedhman wrote:
On Monday 24 March 2003 17:25, Christian Haul wrote:
This is an open *source* project, and a couple of things are a lot easier to do at compile time rather than at run time.
Yes, like ./configure --prefix=/usr/local/ make make install for specifying installation directory, right?
Oh, please, that's not the case. Cocoon is *NOT* an application, it's a framework. Our users are developers. They *MUST* be. What's the point of having a joe-user-proof installation system to avoid them to open up the hood when they *will* have to take the engine apart anyway later?
Need to think beyond the power-programmer... Even the casual programmer struggles with configure/make systems, and often fails and leaves.
If the casual programmer is not able to do
> export JAVA_HOME=/usr/java/ > ./build.sh webapp > ./cocoon.sh servlet
that it does *US* a favor if he fails and leaves. Open source is not about market share, it's about solid communities.
Cocoon cuts across a number of different disciplines (java, xml at least?) and so "casual programmer" means different things.
Very true.
I am amazed at the number of people on users who claim to know no java.
Yes. This is going to be even more with the introduction of the flow since people with client-side knowledge (html + css + javascript + xml + namespace + xslt) will be able to write full-blown web applications with database connectivity *without* a single line of a language they don't know nor understand.
This is potentially *HUGE*. Yet is a community shift that might find *ourselves* not-prepared to stand the flood of those people and their mindsets because most of us don't come from that background and people in that client-side-web background have no notion of SoC, IoC nor any abstract concept like OOP, COP or AOP, nor even the most basic design patterns.
This cultural clash is potentially *very* harmful for both sides if the mindset transition is not done smoothly.
They must be xml/xslt programmers which _may_ mean some combination of: - they don't usually use the command line for anything
true
- they may be installing java for the first time, which (because of sun's windows installer) may have no idea what JAVA_HOME is or should be. They'll need to know this regardless, we just have to add even this to the list of hurdles they already need to jump.
for windows, the sun's installer copies java.exe in the PATH, so we need to have them set JAVA_HOME *ONLY* if there is no java.exe available in path.
- they have never built any software from source, which means if our build fails for them for any reason, they will assume that Cocoon doesn't work, or is too complicated for them. some may turn away if "build" seems too mysterious to them
true
- a few other points I can't remember now along similar lines.
I'm not saying I'm against this idea at all - in fact it has some great benefits. I'm just trying to clarify the psychological barriers I see that need to be taken into account in *how* it's done.
and this is valuable input.
Stefano's point about hiding the build behind configuring and installing is a good one, as long as the build time stays relatively low. 10 minutes _max_ for a full build (which most people won't do) would keep things reasonable IMHO.
I think we meet that time-period on almost any modern machine. Even on my old laptop that was more or less so.
I think I like the jnlp option, if it's not required (was jnlp even available with jdk1.3?) and even though I have little GUI skills and no experience with jnlp, I'd be willing to help work on that.
I think this is YAGNI.
I say: let's start incrementally: we build one well-done build.sh-driven distro and see what is the user reaction. *then* move from there.
What do you think?
Stefano.
