cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: [Jam3s][RT] Turbine for User Repository?
Date Tue, 14 Jan 2003 17:14:15 GMT
I agree with Quinton's cautious approach,

> I agree that there would be benefits from Turbine services being
> Avalonized.  These benefits are mainly for other applications that would
> be able to make use of the code.

It might be nice for James to use Turbine's user-system service, I've looked
at Turbine in the past and though I didn't use it its well designed, and I
know its been well tested.

> There is a benefit to the Turbine user base of having more people using
> the various services.  This benefit would be in the form of better
> tested code.  It could *possibly* also appear in the form of more
> contributions to the code base due to the wider acceptance.

This benefit would also benefit James, Turbine providing a more robust and
well tested service than James' standard users system.

> Right now, I am more concerned about focusing on the needs of the
> current users base.  It is not that I don't care about the Turbine
> services being portable to other projects.  That would be a very good
> thing.  It turns into a bad thing very quickly if we start to run off
> ANY of our current developers or users.

I echo this from the other side, although James system may not be
Magnificent, it is simple, usable, proven and stable.
Whats more it is under our control, one recurring issue we have had with
Avalon is that it is not easy to simply be a consumer of Avalon products
without also having to become a lurker on avalon lists, a developer and even
a contributor. I'd rather that code was explicitly part of James if it is
going to need attention, or undergo revolutionary change.

I'd be happy to see an avalonised turbine user system service available as
an option to consider for James, particularly if it could be selected by
installation or configuration to replace the standard offering. giving users
a choice.

What I'd want to avoid would be primarily stalling James development, but
also introducing bugs/performance problems into a crucial sub-system.

> If some of the committers want to work on this in a separate branch, I
> see nothing wrong with it.  It is simply an experiment and we can see
> where it goes.

If this does happen I'd be happy to evaluate it for James, and provide
feedback, but I'm not in a position (timewise) to be more pro-active.

d.


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


Mime
View raw message