xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Bowditch <bowditch_ch...@hotmail.com>
Subject Re: XML Graphics Commons: last call
Date Thu, 11 Aug 2005 08:21:22 GMT
Thomas DeWeese wrote:


>    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).

I don't understand why passing a configuration object around an 
application should be considered a programmer hack. It's common and well 
accepted practise. Can you elaborate a bit on why you think it's a hack?

>    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.

Your reason why a flame war should result is not clear to me. If you 
can't/won't suggest an alternative then you seem to be on weak ground 
when arguing against something.

>>>> 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.

Agreed that the application may need to provide implementations of 
anything specific - but the classes we are talking about are deemed to 
be generic.

>> 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 understand the concern about adding a new dependency and agree size is 
somewhat irrelevant. The alternative is to rewrite everything yourself 
which isn't very good either.


>> I don't see how logging disturbs operation in interactive contexts. 
>    It doesn't necessarily disturb it but it doesn't help either.

Not true. Logging is extremely helpful when debugging problems raised by 
a remote user. And since all our users are remote and supported by the 
mailing list logging is vital to supporting our users.

>> 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.

Well thats fine for development, but no help for supporting remote 
users. To tell a user where the source code is and they should figure it 
out themselves is not acceptable. A small percentage of users may be 
happy to do this, but most will not be java savy and will expect help 
from the developers.

>> 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.

FOP doesn't have a GUI and whilst Batik may have a GUI in some 
circumstances - there are other use cases - such as transcoders (that 
you already mentioned) and embedded use of Batik where logging is 
necessary to provide feedback of what Batik is doing.


>    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.

You may be right here, but your earlier arguments are not related IMO.

>> 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.

Who said anything about creating empty directories? Empty ones won't be 
helpful, but breaking up big packages into smaller ones makes the code 
easier to get to grips with.

>> 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.

I guess you have a point here. Splitting up large packages into small 
ones helps understanding not the design.


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

View raw message