Giacomo Pati wrote: > > On Tue, 30 Oct 2001, Carsten Ziegeler wrote: > > > Hi Avalon Team, hi Cocoon Team, > > > > we had some weeks ago discussions about moving common > > components from Cocoon to Avalon. Both communitites > > agreed to this step. > > > > So, I think we should now start to identify the components > > we could give to Avalon. As a first start I would > > propose the following: > > > > - XML Parser > > - XSLT Processor > > - XPath > > - Resolver (Entity Resolver) > > - XMLSerializer/XMLDeserializer (The XML to byte stream > > compiler/interpreter) > > - SourceHandler/SourceFactory/Source > > +1 on all above > > > One of the most important components I think is the SourceHandler which > > is a replacement of the java.net.URL classes. It allows to define own > > protocols > > (like cocoon:, or cvs: etc) in a server environment. Many > projects (Cocoon, > > Batik, perhaps soon FOP etc) have their own implementations which makes > > integrating > > same difficult and sometimes impossible. > > This means we have to convice them to change from URL to SourceHandler > to have a smooth integration into Cocoon, right? > Yes, more or less, e.g. Batik has already a very similar concept to our SourceHandler, so the transition for either them or us would be very easy. The transition from the "usual" URL approach, of course, is an unavoidable step. But as we have the experince from this step when we changed Cocoon, this was a rather small step. So this should apply to all other projects already using Avalon as well. The main part will be the switch to Avalon if they haven't already done.
> > In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml > > package), > > like XMLConsumer, XMLizable etc which are right placed in Avalon, too. > > +1, there package/classes/interfaces will interfer with the one above > because an XSLTProcessor is an XMLConsumer. Should the Abstract > implementations move into Excalibur as well? > Yes, adding abstract implementations is always useful. So they should move, too. Carsten > > If we have identified the components to move/donate, we should > start discuss > > if they should be moved unchanged or if they could be redesigned. But > > this should be the second step. > > > > So, are there more components we could donate? > > Avalon Team, are you interested in this? > > > > What's the correct procedure for this? > > > > Carsten > > > > Open Source Group sunShine - b:Integrated > > ================================================================ > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn > > www.sundn.de mailto: [EMAIL PROTECTED] > > ================================================================ > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
