Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <39A63F8E.F3D66AB1@apache.org>
Date: Fri, 25 Aug 2000 11:42:38 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Would like to contribute
References: <3996C187.561B8098@ispsoft.de> <39985BD0.8B599622@apache.org>
 <39A551FE.A0E1FFBF@ispsoft.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jochen Wiedmann wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > I would love to be able to provide hosting space for "commercial
> > connectors" in the official site, but integrating them into the distro
> > could be dangerous.
> >
> > Anyway, I'm very interested in the contribution since people might find
> > it useful.
> 
> The subject is still open, isn't it?

Sure, the problem is that I don't know where to put those contributions
:/
 
> Btw, I personally can't see any problems with producers and/or
> processors related to commercial software. Note that the SQL
> and LDAP stuff is closely related to the same things.

Nah, wrong: it's not a problem related "to commercial software", not at
all. It's a problem related to "proprietary API or protocols". Both LDAP
and SQL are non-proprietary standards, in the sense that there are
_several_ products (both commercial and open source) that implement
those protocols.

Here we have something that connects to a specific XML database (which I
don't judge on the technical merits, not at all!) with a specific
interface that is not recognized as a standard.

So while SQLProducer is fine (even if it doesn't work out of the box,
c'mon, that's not an argument), PostgreSQLProducer is not! even if the
software is open, freely available and implements an industrial
standard.

This, again, doesn't rule out the possibility to have such proprietary
connectors (such as Prism, which connects directly to Oracle and
features that only Oracle has, or your own) "somewhere" around the
Cocoon official distribution side.

A possible solution would be to create a subdirectory in 

  xml.apache.org/cocoon/dist/contrib

which I'm _very_ happy to provide. We can do this tomorrow if you want
(and put Prism in there as well, if you care and any other proprietary
modules you guys might have but don't want to include in the main
distribution).

The problem is that while helpful, this doesn't create a community
around those tools and it's likely to generate feedback/questions on the
cocoon mail lists without us able to provide direct community support.

I don't like this.

At the same time, creating a new subproject for every module is simply
too much to ask (believe me, I know what I'm talking about, expecially
these days when the ASF members are having a big discussion about
removing project containers such as xml.apache.org and
jakarta.apache.org and flatten the project stucture).

So I'm stuck.

Well, this is the plan:

1) we create this "contrib" directory and place those modules there.
Active developers will act as proxies for placing those component little
distro in there.

2) if/when the contributions take off, people use them and they start
having feedback/requests/code/fixes and such to an amount the original
author can't stand anymore, we'll think about what to do next. At that
point, including in the main distribution is an option, provided that
enough people request for it.

Now up to you to judge/patch my action plan.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------