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

[COFFMAN Steven <SC...@COVANSYS.com>]

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.

-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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

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

[Mark Lillywhite <ma...@inomial.com>]

> 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.

I remember wishing that I didn't have to make the API changes because,
well, public API changes are bad, ok? But in the end it was necessary
because the old API implicitly assumes that the FO tree building is
separate from the formatting/rendering, which is no longer the case.

I can't imagine how one would write a compatability layer.

(As an aside I will be away on holidays from Sunday - thankfully out of
the reach of my laptop (unless someone posts it to a small island in
thailand ;). So if anyone has questions/comments/abuse then you'll have
to wait till I get back. :-)

Cheers
Mark


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

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

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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org