cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Donating Cocoon Components to Avalon
Date Tue, 30 Oct 2001 16:16:12 GMT
> Berin Loritsch wrote:
>
> giacomo 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
>
> Neeme started on the XPath Component so he can use it for i18n
>
> > > 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?
>
> Batik already has it's own mechanism which is also very nice.  It might
> be worth it to take a look at it.  FOP doesn't have anything like that,
> I placed a feature enhancement request into BugZilla for them, but no
> activity has happened on it yet.
>
> > > 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?
>
> As long as they are not Cocoon specific.
>
> > > 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?
>
> We are interested in it.  We just have limited time.
>
> > > What's the correct procedure for this?
>
> Find someone with the time....
>
Hm, OK, is there someone with time for it in the Avalon Team?
I would propose myself (being a little bit egoistic),
but unfortunately I'm not an Avalon comitter.

Carsten

>
> --
>
> "Those who would trade liberty for
>  temporary security deserve neither"
>                 - Benjamin Franklin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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


Mime
View raw message