> -----Original Message-----
> From: Steven Noels [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 25, 2003 11:10 AM
> To: [EMAIL PROTECTED]
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
>
> Sure. If more people, and hopefully Tom and other Wings folks, become
> stewards of 'the' Cocoon charting codebase, we can commit either
> solution, or both, or one solution as we see fit. But as I said in the
> SAP R/3 case, this won't solve the problem of the corpulent codebase,
> and the issues with oversight that comes with its weight. Your efforts
> in blockifying stuff have already unearthed several issues, and I think
> we should actively try to keep the core codebase clean & healthy.
>
Steven, this begs another question: what's should be inside Cocoon ?
Or, more to the point, should a chart-producing package be inserted in the codebase ?
A) If the answer is yes (as it is now), sooner or later a decision should be made
between Wings and ChartTransformer (supporting
both doesn't seem sensible to me ).
B) If the answer is no, then delete Wings from the codebase and insert in the doc that
users can create charts with Cocoon by
downloading Wings and/or ChartTransformer from Krysalis and/or CocoonDev.
Well, in all fairness, I'd like "my" package to enter into the standard Cocoon
distro... partly because I need to feed my ego (the
Nirvana is still ahead of me ;) ), partly because I think that it could be a good
selling point for Cocoon.
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
[EMAIL PROTECTED]
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> -----Original Message-----
> From: Steven Noels [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 25, 2003 11:10 AM
> To: [EMAIL PROTECTED]
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
>
>
> Nicola Ken Barozzi wrote:
>
> > In Cocoon we already have a chart transformer, based on Krysalis Wings.
> > It has evolved, and now we use JCharts, that is APL compatible.
>
> Evolved? It requires some serious work, you mean. You are overselling
> Wings, Nicola. Wings has a committers base which is rather inactive, and
> the Cocoon stuff is quite poor feature-wise when compared to
> ChartTransformer.
>
> (don't start defending Wings or its committers base, I know Tom very
> well and I know he can cope with such a message - especially since we
> (xreporter) are one of the few who actually tried to put it to use)
>
> > Wings has the possibility of using different charting packages as
> > back-ends, and JFreechart too, but it ships with jCharts as default.
> >
> > I'd personally prefer that we use a completely APL-compatible system for
> > charting. Overmore Wings has been developed with separation of content
> > and syle in mind...
> >
> > Anyway, I really don't want to stop this, but I'd like that we decide
> > what we want to do.
> >
> > The fact is that putting something in Cocoon CVS makes it somewhat
> > "standard". If this solution had been there for some time, it would be a
> > sure bet, and can be inserted by name.
>
> It has been suggested before that ChartTransformer and Wings could
> cooperate, but due to time-to-market and technical issues, each group
> went its own way. So be it. Software Darwinism.
>
> From a Cocoon perspective, this is the nth example of my recurrent
> theme/worry that we are adding too much stuff to the core CVS. Or we
> should make more active use of the cocoon-apps module, or stuff should
> be moved to cocoondev.org. Either way I'm happy. Blocks ain't good
> enough, if the xml-cocoon2 repository keeps on growing in terms of size.
>
> I loath to see people creating stuff outside this community, but with
> the intent to have it moved into Cocoon afterwards. Sorry to say so, and
> please don't take this as a criticism. I think, given our new
> independence and responsability that comes with being being a toplevel
> project, we should worry about long-term oversight of Cocoon code (and
> don't be mad, Luca, it's with the best intentions). AAMOF, I proposed to
> Luca to move to cocoondev.org minutes after seeing his mail, so that we
> get a publicly accessible CVS repository.
>
> > In this case we have two different charting transformers, which to insert?
> >
> > IMHO the best thing at the moment, and I repeat ATM and IMVHO, is that
> > this transformer be hosted on cocoondev so that it can grow.
> > And I'd like that we get to combine efforts, so that we can commit a
> > unified version to the Cocoon CVS.
>
> Sure. If more people, and hopefully Tom and other Wings folks, become
> stewards of 'the' Cocoon charting codebase, we can commit either
> solution, or both, or one solution as we see fit. But as I said in the
> SAP R/3 case, this won't solve the problem of the corpulent codebase,
> and the issues with oversight that comes with its weight. Your efforts
> in blockifying stuff have already unearthed several issues, and I think
> we should actively try to keep the core codebase clean & healthy.
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at http://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.org stevenn at apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
