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

[Sam Ruby <ru...@us.ibm.com>]

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

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

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

At 10:33 AM 8/9/01 -0400, Sam Ruby wrote:
>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.

Sam, I figure you meant the "perennially in alpha" comment sort of 
tongue-in-cheek. I hope you did, anyway. Still, it's not the kind of 
observation, serious or otherwise, that fills me with joy. I suspect you 
might not be the only one who thinks FOP is a bit of a lame duck. I'm sorry 
if FOP is perceived that way - the fact is, we don't have any high-powered 
big companies throwing huge chunks of resources or code in our direction, 
all of us work at real jobs which usually have little or nothing to do with 
XSL or FOP, and apparently most of us have social lives. It's also worth 
pointing out that the XSL spec is large, has plenty of loopholes and 
ambiguities still, and isn't even a Recommendation yet. The problem of 
formatting pages is highly complex - just go out and ask people that have 
been doing it for a while. I'd say that the inherent problem is considerably 
more complex than processing XML or XSL.

Ask yourself how well you think Xerces or Xalan would be doing if they had 
been donated a starter chunk of code that covered maybe 25% of an obsolete 
early version of their respective specs, and had never had any full-time 
bodies assigned to them either.

Let's get one thing straight - we're not in alpha. We're not even close to 
alpha.

You're on the XML PMC...it would be nice to hear constructive suggestions 
rather than snide comments.

Regards,
Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


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