cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Cocoon web applications
Date Mon, 08 Oct 2001 16:42:01 GMT
-- Michael Hartle wrote:
> 
> Stefano Mazzocchi wrote:
> 
> >>large CWAs are going to happen (they will, right ?), the sheer length of
> >>the list of "parameters" for customizing them could well justify this
> >>approach.
> >>
> >Well, I don't think the number of parameters depend on the size of the
> >CWA being deployed and I don't think I get your point.
> >
> With "large" CWAs I meant possibly as complex systems as project
> management, groupware or financial/commercial components. The interest
> in developing off-the-shelf drop-in CWAs that can be composed and
> interconnected will more likely lead to more configuration options
> (parameters) than not. Maybe you have another estimation on that.

To be honest, I think it will depend, but generally, I'd tend to assume
that rather than passing tons of parameters, one might pass the name of
the directory server (or other type of repository) that contains them.

But I might well be wrong.
 
> If those configuration options/parameters are not being passed or
> maintained by defined means of Cocoon, each CWA will solve this problem
> on their own by web forms or seperate configuration files, unnecessarily
> duplicating work of developers and maybe hinder the use of CWAs.

Here I completely agree.
 
We'll see: if a small number of configurations are required for each
CWA, then a 'lookup' on a configuration registry is, IMO, the way to go.
If, on the other hand, a massive flow of highly structured and possibly
namespaced configurations will be required (but I'd suggest against it
unless we want to deal with broken contracts between CWAs), then a IoC
mechanism will be better suited.

> >>This would even allow passing on an instance of configuration source to
> >>the CWA, this instance implementing some ConfigurationSource-interface -
> >>be aware that I am not sure whether such an interface or class with this
> >>name is already existing, and I am not knowingly referring to anything
> >>here as I just made a wild guess how this could be named. This might be
> >>an LDAPConfigurationSource or a FileConfigurationSource, being able to
> >>deliver arbitrary configuration information to the CWA as a stream of
> >>SAX events.
> >>
> >
> >Normally, configurations are strings or numbers. Do you really want to
> >receive a stream of SAX events that you have to write your own code to
> >interpret, instead of being able to simply *ask* a configuration
> >repository for the configuration you want?
> >
> I think we basically misunderstood each other in respect to the amount
> of information that may be required as configuration for a CWA; I so far
> am thinking that this might not be done with passing 2 or 3 name/value
> pairs to any app. I consider the term configuration to be a potentially
> hierarchical collection of one or more key/value combinations.
> 
> Ok, I agree with you on the part that many small and simple applications
> will be satisfied with just asking for one or two strings or numbers.
> Why not basically use SAX events, giving small applications some utility
> classes at hand that helps doing exactly and solely this while
> developers of more complex apps might decide for themselves what they need ?

I'm not against using SAX 'per se'. I'm more against passing a high
number of parameters and making it easier for the CWA developer to
receive a load of them... but this is unless talking without real-life
examples.

Anyway, I think of CWA as the web equivalent of avalon blocks and blocks
receive a configuration instance that incapsulates the conf structure
they need and the block queries the configuration it needs.

I fail to see why such a system cannot scale with the amount of
configurations required by CWA. In fact, directory servers was created
exactly to allow tree-like structures to scale (given the difficulty of
providing a fast relational view of a tree).

Also, as a developer, I would not find it easier to have to intercept a
bunch of SAX events, store them someplace, retrieve them later and
manage their caching/lookup-strategy, etc...

I'd rather receive a configuration repository with a solid hierarchical
structure and pruned for my own configurations, then ask for what I need
when I need it without caring about how to get it.

Admittedly, this is not IoC since you are calling directly an API, but
there are situations where normal flow of control is preferrable and
this is, IMO, one of such places.
 
> >>And those ConfigurationSource's could be defined in the
> >>sitemap and being configured with parameters when needed. Hey, why not
> >>simply consider different configuration sources as sources for SAX
> >>events directly ?
> >>
> >Because this is exactly what flexiblity syndrome looks like: when you
> >have a hammer in your hand, everything looks like a nail.
> >
> I rather like to open-mindedly check everything in advance before
> stepping into nails; this does not necessarily mean that this
> flexibility needs to be exercised all the way through, but left as a
> possible way to go in case it is needed.

Absolutely.
 
> >>>each CWA indicates
> >>>   o  its role as a URI  (http://apache.org/cocoon/webapp)
> >>>
> What about putting the version in major.minor format into the URI, like
> it is being done with namespace URIs like
> "http://apache.org/cocoon/LDAP/1.0" or
> "http://apache.org/cocoon/include/1.0" ?

Yes, this is another alternative and might appear more coherent with our
use of namespace URIs if we all start using them correctly: means that
we *must* make sure that version numbers maintain their semantic meaning
that if major numbers are equal, namespaces are compatible, otherwise
they are not.
 
> >>I am always fearful of prompts that do something for me that I may not
> >>have understood completely.
> >>
> >This is why the CWA will also contain a description of the configuration
> >that you are being asked to provide.
> >
> I will correct my sentence: I am always fearful of automated processes
> and prompts that do something for me that I should at least once have
> done for myself manually in order to understand it completely.

Ok, got your feeling and I think you raise a good cognitive point: who
should we address this mechanism? people used to install and configurre
software with point and click installers and GUI tools (admittedly, I'm
one of those) or people used to install software from the command line
and configure it thru text editing?

I think we should target both, mostly because that will make it easier
for people coming on the server market from non-unix backgrounds
(admittedly, I'm one of those, again) to install, configure and create
their own complex website using our lego-like CWA components.

And, BTW, MacOSX shows that having two choices (GUIs and CLIs) gives you
such a great feeling of ease-of-use without sacrificing the power to
control the system at the very granular level of single configurations.
 
> >>Do we speak of a solely installer-based
> >>approach here or might this allow the admin to just drop-in the .cwa
> >>file and add an entry to the sitemap without anything able to directly
> >>prompt at all ?
> >>
> >As you guys wish, I don't see any reason to force one behavior or the
> >other.
> >
> I think the installer-based approach with prompting the user is
> something to be left for a seperate deployment tool.

It might be, but it has to connect directly to the system and people
will trust less a package that you have to install afterwords and has to
connect to cocoon core to operate.

If we had such a tool, I'd rather ship it with cocoon while letting you
turn it off (for whatever reason).
 
> >>We should give the administrator a way to explicitly name a certain
> >>instance, leaving the administrator the choice between automatic
> >>GUI-driven and good-old vi-driven approaches, as the admin can partially
> >>or completely override the naming scheme and refer CWA dependencies to
> >>their targets manually. Whenever people would use the dynamic naming
> >>scheme to ensure multiple installations do not collide, they show a
> >>certain lack of interest to make sure they connect CWA dependencies
> >>correctly.
> >>
> >You got the wrong perception here, since I'm trying to help
> >administrators instead of doing stuff for them behind their backs. But
> >if you don't like that, fine, you'll always have the good old
> >configuration files to modify by hand.
> >
> Helping administrators is a good thing and will certainly be rewarded; I
> am by no means having a vi fetish, but I think that being able to modify
> the configurations by hand has its advantages such as speed.

Agreed.

Believe me: even if I was raised on GUIs and still know only a few basic
VI commands, I do appreciate the power of being able to reconfigure a
server by simply editing a few lines you know very well and without
going to a nightmare of clicks.

But on the other hand, newbies or people not really "deep" into that,
might just want a nice and simple visual interface to do their stuff and
start learning.

Don't worry, we won't sacrifice one for the other.

--
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message