xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: XML Graphics Commons: last call
Date Thu, 11 Aug 2005 00:34:35 GMT
Jeremias Maerki wrote:
> On 09.08.2005 13:12:18 Thomas DeWeese wrote:


>>>On 08.08.2005 22:31:09 J.Pietschmann wrote:
>>
>>>>2. Seeing Avalon as dependency makes me uneasy. I'd prefer
>>>>commons code to be refactored to not using Avalon and to
>>>>provide raw functionality only.
>>
>>    So I am a bit concerned about the addition of three new
>>external dependencies for Batik.  I realize that some of it is
>>already there but hidden in the PDF transcoder.
>>
>>Jeremias Maerki wrote:
>>
>>>Everybody always complains about that little library. What's the problem?
>>>We're not going to do Avalonization anymore. But the configuration
>>>subpackage in A-F is a perfect (!) little tool and a LOT smaller than
>>>Jakarta Commons Configuration. 
>>
>>    What are we configuring?
> 
> Fonts and optional PDF-fine-tuning, mostly. Not everything that could
> also be configured in FOP 0.20.5 is already implemented in the trunk.

    Ok so I took some time and I really don't like this model.
This is exactly the sort of thing that belongs at the application
layer not at the library layer.  The idea of 'passing data' around
the application through a config file seems really bad to me.
(it's an excellent example of a programmers hack, look at all the
cool stuff I can do, so I can also break things in really odd
unpredictable ways - that's a small price to pay for tweakability).

    The problem is that I'm sure this is exactly the sort of
thing that sparked the flame wars.  I also am not going to even
come close to have the time or interest to provide a replacement.

>>>If anything, those who have a problem
>>>with A-F should propose a viable alternative (I haven't seen one, yet)
>>>or work with the Excalibur guys to extract the configuration subpackage
>>>into a stand-alone lib.
>>
>>    Since I have no idea what the library is and/or what you
>>plan to use it for I can't really provide alternatives.

    This should be done the old fashioned way, the library should export
interfaces to support configuration and the _application_ should
provide the configuration data to the library as appropriate for
the application.  I think this is really trying to do an end run
around this.  There is no clear description of the data that passes
across this interface - that's really ugly IMO.

> But A-F contains a configuration subpackage [2] which is very small,
> very easy to use and provides exactly what is necessary to load a
> configuration tree from an XML file and to access values in a type-safe
> and fail-safe manner while not having to deal with the deficiencies of a
> DOM.

    The problem is that I don't care how big or small a dependency is
once the dependency is there it causes problems.

>>    I'm also not thrilled with adding lots of logging dependencies. 
>>Logging makes sense for 'non-interactive' contexts but is not really
>>what you want for most interactive contexts.
> 
> AFAICS there is exactly one dependency on Commons Logging. Avalon
> Logging is not used anymore.

    Once again it doesn't matter how big or small the dependency is
a dependency is a dependency.  Also the lots of logging dependencies
come from the pervasiveness of logging.  Once you are in it's hard
to change.

    So what is common's I/O used for?  I assumed it was used for
Logging.

> I don't see how logging disturbs operation in interactive contexts. 

    It doesn't necessarily disturb it but it doesn't help either.

> Do you prefer logging by System.out? Or can you do without logging? 

    I add/uncomment system.err messages (and often make use
of 'new Error("blah").printStackTrace()') as needed to track problems.
In the past I've developed elaborate logging systems (mostly C/C++)
and they can be useful for situations where build times are long
or you need to support remote clients.  But Java build times are tiny
and end users can access our source.

> I learned that I can't. Logging is a very powerful means while
> debugging (dev- and deployment-time).

    As I said logging can be useful in non-interactive circumstances,
but in interactive situations you need to provide feedback through
the GUI.  In my experience logging is useless for this - the type
and style of messages that goes into logs is very different from
the GUI.  Now there are potentially non-interactive applications
for Batik components (the transcoders mostly) but right now they
handle logging/notification through the UserAgent classes.

>>---
>>
>>Other comments:
>>
>>    You should probably add 'SVGGraphics2D' to the java2D tree,
>>and possible components coming from Batik.
> 
> 
> Done. Remember, it's a Wiki! And we get change logs on
> commits@xmlgraphics.apache.org. :-)
> 
> 
>>    I'm not sure what the intent of the code structure is.  It
>>looks like each of the 'parts' is intended to be an independent
>>'project' (i.e. separate source tree's).  Would it make more
>>sense to just have one source tree and separate based on
>>packages (this is what batik does to build it's sub jars)?
> 
> That's one possibility but people have a hard time understanding what is
> in which of the batik JARs. 

    I'm not sure that splitting the code up helps here.  I think it
makes the problem worse (which tree is the stuff I need in?).

> Like FOP, Batik is a big blob of code. What I intend with the 
> split is to make it easier and (more importantly) less overwhelming 
> for newbies to start working on certain parts. FOP is scary
> and so is Batik. Experience shows that despite a clean package structure,
> people still don't find their way. I don't say that my proposal will
> definitely solve that problem but I suspect it might help. At any rate,
> this is an aspect that we need to take very seriously. Batik (even more
> than FOP) needs to attract new contributors. What happens if you and/or
> Cameron suddenly go inactive? There's no one left. Project dies. (Sorry,
> my PMC hat shows here)

    I'm happy to split out independent pieces but in my opinion they
are either completely separate project (independent releases possible)
or they should be one code base.  I think the 1/2 way solution is
just annoying for everyone.

> Is that plausible?
> 
> 
>>    The current system seems like a lot of extra build nonsense
>>since each jar has to be built in turn so it can be used to
>>compile the next project, right?
> 
> Not necessarily. I don't think a separate build for each package is
> necessary. I think it's simply helpful to more clearly show to
> interested people what the individual parts are. 

    Isn't this better done in the documentation?  I fail to see how
introducing a bunch of extra empty directories does anything to
help comprehension.  And as long as you have one big build you
don't even get enforcement of unidirectional dependencies.

> This also favors a cleaner design which is an additional benefit. 
> I think Victor Mote could tell you a good tale how he alone 
> already profited from dividing FOray (a FOP fork) into digestable 
> chunks. 

    My point is that it doesn't do anything for good design.  There
is no advantage to this split from a design point of view.


---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org


Mime
View raw message