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 interface. 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? Thanks, Mike. -- Michael Gratton <[EMAIL PROTECTED]> Recall Design <http://www.recalldesign.com/> s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555
smime.p7s
Description: S/MIME Cryptographic Signature
