cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [proposal] a new kind of 'dist'
Date Mon, 24 Mar 2003 14:03:34 GMT
Geoff Howard wrote:
> 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.



Mime
View raw message