RE: Public API Change in Driver (Was Re: [GUMP] Build Failure - C ocoon2)

[giacomo <gi...@apache.org>]

On Thu, 9 Aug 2001, COFFMAN Steven wrote:

> We are very comitted to keeping all FOP and Cocoon releases in sync. When
> Cocoon changes Xerces and Xalan versions and JDK versions, so does FOP.
>
> We plan on making a new release of FOP this weekend, and at minimum we would
> also submit a patch to Cocoon for it to use the new API so the next release
> of Cocoon2 would sync with FOP.
>
> FOP underwent some major refactoring to massively reduce memory usage, and
> it might not be possible to make a workable deprecated API for backwards
> compatibility. (Mark?) We don't break API compatibility lightly, and don't
> expect to have to do so again in the foreseeable future. Sorry for not
> posting to Cocoon-dev earlier what was up.

Steven, thanks for the information. As Cocoon uses FOP in a
serialisation phase of resource production it is not very harmfull to us
as long as FOP's functionallity remains the same (we'll get in trouble
if you would cancel SAX support :) But sure we'd like to stay in sync.
Submitting a patch to the FOPSerializer will be very generous, thank
you.

Giacomo


>
> -Steve
> -----Original Message-----
> From: Sam Ruby [mailto:rubys@us.ibm.com]
> Sent: Thursday, August 09, 2001 10:33 AM
> To: fop-dev@xml.apache.org
> Cc: cocoon-dev@xml.apache.org
> Subject: Re: Public API Change in Driver (Was Re: [GUMP] Build Failure -
> Cocoon2)
>
>
> Weiqi Gao wrote:
> >
> > Sam Ruby wrote:
> > >
> > > It appears that some fop interfaces are changing in a way that
> > > will impact cocoon2... is there work underway to keep these
> > > projects in synch?
> > >
> > > In particular, is there another backwards compatible set of
> > > interfaces that cocoon2 should be using during the transistion?
> >
> > This is probably introduced by Mark's patch.  I have reported this in my
> > report when I tested the patch before the commit (See the thread "FOP in
> a
> > servlet under load").  Mark mentioned it in his web site for the patch
> too.
> >
> > The documentation ("Embedding") should probably be updated by the
> committers
> > to reflect the change.
> >
> > I don't think a backwards compatible interface is needed.  Not for
> something
> > with a version number of 0.19.0, and been characterized as pre-beta,
> > not-production-ready and incomplete.  (If that doesn't buy the project
> the
> > rights to change the public interface at will, we might as well call it
> > version 1.0).
>
> I realize that xml-fop is one of those projects which is perennially in
> alpha.  What I am looking for is concrete suggestions on how Cocoon2 should
> deal with this state.
>
> One possibility is that cocoon2 should drop support for FOP.  I think that
> that would be unfortunate.
>
> Another possibility is that cocoon2 monitor for changes in the public API
> and engages in a dialog to resolve any issues that come up when they arise.
> I am doing the former, and trying to spark an interest in the latter.
>
> A third possibility is for fop to deprecate interfaces for a period of time
> before change.  As you point out, perhaps this suggestion is premature.
>
> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
>


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