xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@infoplanning.com>
Subject Re: Avalon Awareness not worth it
Date Thu, 07 Sep 2000 17:08:54 GMT
COFFMAN Steven wrote:
> FOP is already treated as a black-box Avalon Component by Cocoon 2 (and the
> broken Cocoon 1). Functionally, additional "Avalon-ness" doesn't get FOP
> anything. The software engineering practices are great in theory, but
> they're still evolving and poorly documented at this point, plus they'd
> require a major FOP refactoring. Since FOP development has been "many minor
> patches" rather than an individual spending 40 hours a week on it, I think
> any such goal would just stall FOP out. Once Avalon is better documented and
> stabilized, it'd be good to read it so things can gradually evolve in that
> direction. Or if we get a full time FOP person.

A pitty, but I definitely understand.  Bear with us please.

> The Avalon functionality goodies are only available to services/servers,
> which FOP isn't. When FOP is used as part of one, such as Cocoon, then FOP
> could use Avalon logging, configuration, etc., but you'd have to have
> "if(fopComponentManager == null)" all over the place for CommandLine,
> XTCommandLine, AWTviewer, etc.

We are aiming toward an interim release soon, and in that release the
logger should be a system level component (i.e. available to everyone).
I beleive the Thread Manager is moving in that direction as well.  In the
following release there will be a configuration engine that (should you
need it) you would be able to use.

As to the if (fopComponentManager==null) comment, that is not true.  It
is covered by contract that all Composers are given a useable ComponentManager.
Again, better documentation would help.  I will be working on that once
the release is ready.

> The avalon folks are all jakarta/cocoon/james service/server folks, so
> they're understandably uninterested in adding extra non-server code that
> would make it more attractive to components that also run stand-alone. You
> wouldn't believe how much everything is in flux over there too! They were
> arguing over fundamentals until just recently.

The remodeling is almost over.  We will have a split development tree:
one for proposals and new work, and the other for the released version.
We here your cries and are working on making a stable foundation to work
from.  It is true that our first concern is to service/server applications,
but if there are some general purpose Components you need don't hesitate
to ask.  We have limited resources, but we want to make a very compelling

I hope you don't abandon us altogether, after the next two releases we
should have a stable platform to center development around.  I hope you
continue with your plan for modularly migrating to Avalon Awareness,
but trust me when I say the revolutionary approach definitely isn't
worth the effort just yet.

We have come to consensus about a number of things so it isn't as hostile
as you make it out to be.

View raw message