Sigh, this is getting long, please bear with me here.

Jeremias Maerki wrote:
> Ok, let's look at it that way: With your reasoning people who *can't*
> use Avalon *can't* use Cocoon, for example. But Cocoon only uses Avalon
> internally.

Err, as an application framework unto itself, I would have thought 
Cocoon would be the basis for building an application, not just 
something you'd pull in because you need to do some XML processing. In 
any case, if someone really could not use Avalon, and Cocoon exposed 
non-Avalon interfaces, then there would be no problem. The problem with 
FOP at the moment is *there is no non-Avalon interface*.

To be clear, I'm not talking about developing an application, I'm 
talking about embedding FOP into an existing framework which already has 
it's own logging, configuration and management services.

> What I want to say is the following: FOP users don't necessarily have to
> fiddle with Avalon since we can provide non-avalon interfaces for the
> outside world.

Users don't, but embedders do. I know because I just tried. Right now, 
no such non-Avalon interfaces exist. My proposal provides that 
non-Avalon interface for logging.

> Actually, your proposal and mine are exactly the same except that I'd
> like to use existing code. You introduce more FOP-specific stuff that we
> have to maintain and support.

Yep, and I still maintain that the once-off amounts of additional code 
(tiny) and the effort to maintain it (tiny, if any) is far offset by the 
benfit to emedders (great).

Actually, the amount of maintanence potentially goes *down*. When the 
Avalon interfaces inevitably change (which they already have: did you 
know that Loggable is deprecated?), at the moment you'll need to go 
through all of the FOP code and make those changes. Using an interface 
to it like LoggingHandler, you change one classs: the Logkit handler.

> When we introduce your logging idea (It's a good one I just happen to
> think there's a better one) we start something like that again.

No, to my mind it is a different story - although if LoggingHandlers 
appeard in FOP for other logging mechanisms, such as 1.4's, it would be 
the same story. As I said before, I'm all for code reuse. By all means, 
use Batik for rendering SVG, use Excalibur's URIResolver, but of FOP is 
going to be widely used by embedders, you want to keep the amount of 
additional work required to embedd it down to a bare minimum.

>>The LogkitLoggingHandler class provides a transparent 
>>wrapper for using Logkit and Avalon with FOP. 
> Avalon is no logger. It has logger facilities exactly for the same
> reason that we need one for FOP. So why don't we use Avalon's?

I didn't mean to imply it was - I was saying that the 
LogkitLoggingHandler can be used as a Avalon Loggable object - i.e., one 
that can do some logging, so it still fits nicely into the Avalon framework.

> That would mean LoggingHandler wraps Avalon's Logger interface which in
> turns wraps Logkit, Log4J, JDK14Logger etc. No benefit here, I think.

No, LoggkitLoggingHandler wraps Avalon's Logger, and implements the 
LoggingHandler interface. The benefit is to embedders who don't want to 
use Avalon - they provide their own implementation of LoggingHandler.

> I wouldn't trade in code reuse for a reduced number of jars. When this
> is really a problem you can always repack jars, so fop.jar, for
> example, includes the things needed from Avalon. (as I already said).

But I'm *not talking about less code reuse*.

It's *not* the number of jars that is the problem - it's the additional 
amount of code that a developer must be familiar with to effectively 
use, develop against, debug and support.

> Because Avalon's Logger interface is almost exactly the same as yours.
> And because we don't have to reinvent the wheel.

No, I defined an interface to a logging mechanism. Logkit *is* a logging 
mechanism. There's a *huge*, *massive* difference here. I can't 
emphasize that enough.

> Granted, we (may) have one more jar (avalon-framework.jar) but when we
> want to use Avalon some more (Caching, URI Resolving etc) we have to
> include it anyway (ok, probabaly another one: avalon-excalibur.jar). And
> FOP can concentrate on layout....

Right, but embedders don't have to care about how FOP resolves a URI, or 
does it's caching, it's all internal, and as long it is kept purely 
internal, it does *not* matter. It's the external interfaces to FOP that 
embedders care about. For FOP to be used by developers, it *must* not 
impose undue constraints on them. Pigoenholing them into using a 
particular framework or forcing them to write translation layers from 
that framework to theirs *is* an undue constraint, regardless of how you 
attempt to justify it.

Take Mozilla for example. Moz uses some outstanding technologies, XPCOM, 
Gecko, Necko, libpr0n, XUL, XBL, Spidermonkey, etc, etc, etc. People use 
Moz for browsing the web, and they indirectly benefit from all of these 
technologies. Developers also want to use Mozilla's great rendering 
engine - Gecko - to provide HTML rendering capbilities for their 
application. Gecko uses internally many Mozilla technologies and is 
wrapped by others for the actual browser itself, but those developers 
just want to Gecko, they don't want to know and don't care about XPCOM, 
or XUL, or libpr0n, just so long at Gecko does it's job. Mozilla's 
developers recognised this, have built Mozilla accordingly, and so now 
you can embed Mozilla in C/C++ and Java applications without knowing or 
caring about the underlying technologies used. Hell, there's even an 
ActiveX wrapper for Gecko so you can embed it in IE. As a result, many 
developers have embedded Gecko, and everyone wins. If these developers 
had had to learn XPCOM, XUL, XBL and everything else, then there's 
little chance they would have embedded Gecko, and everyone loses. Note 
that developers could choose to use some of these other technologies, 
but in most cases, they didn't.

FOP is in the same boat. If FOP is going to be widely embedded, it needs 
to expose a core framework-independent and architecture-independent 

Look, does anyone else out there agree or disagree with me? Am I 
flogging a dead horse? Barking up the wrong tree?

Committers, am I wasting my time here?


Michael Gratton <[EMAIL PROTECTED]>
Recall Design <>
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to