From cocoon-dev-return-16030-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Thu Aug 09 16:03:39 2001 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 37642 invoked by uid 500); 9 Aug 2001 16:03:39 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Delivered-To: moderator for cocoon-dev@xml.apache.org Received: (qmail 41383 invoked from network); 9 Aug 2001 15:18:44 -0000 Message-ID: From: COFFMAN Steven To: "'cocoon-dev@xml.apache.org'" , fop-dev@xml.apache.org Subject: RE: Public API Change in Driver (Was Re: [GUMP] Build Failure - C ocoon2) Date: Thu, 9 Aug 2001 11:17:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org