cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Donating Cocoon Components to Avalon
Date Tue, 30 Oct 2001 16:12:17 GMT
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....


-- 

"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


Mime
View raw message