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 11:50:24 GMT
Hi Thomas,

thanks for clearing up the points I raised. What you are saying is now a 
lot clearer to me.

Thomas DeWeese wrote:


>    AFAIKS there is no explicit documentation of what the
> configuration object's interface is.  It's what ever the file
> happens to contain and the library happens to want to pull out.
> This interface is totally free to change at any point in time.

I understand your objection now. You mean you don't like the generic 
nature of the configuration classes.

>    This is bad, IMO it's akin to global variables.  They are really
> easy to manipulate 'outside' of the published interfaces can be
> extremely useful, and make it impossible for the application to
> have a sane view, enforce and/or lockdown he application state.
>> If you can't/won't suggest an alternative then you seem to be on weak 
>> ground when arguing against something.
>    So I did suggest an alternative (it's right below), publish an
> honest to goodness configuration object with a real interface.  Then
> have the application layer populate that through what ever means it
> chooses.  I also admitted that I was in a weak position because there
> was no way I was going to rewrite the 'problem' code.

Ok. That wasn't clear before.

>    But please keep in mind why we are having this discussion.  It
> is because we are in the final stages of deciding how Fop and
> Batik can merge development in common areas.  You will note that
> in this discussion there is no issue around Batik external dependencies
> because there are none.  All of our external dependencies are
> pay as you go (Xalan, rhino, pdf-transcoder,...).  Batik hasn't
> inflicted other projects our users without strong justification.

I seem to remember some pain relating to licensing of Rhino recently. So 
I don't completely agree here. The fact is that both projects need to 
use third party software. It's all about code re-use, ease of 
development etc.

>>>    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.
>    So I'm happy to use libraries that provide significant functionality
> but I don't like adding a dependency for something as silly as
> configuration.  I understand that it 'makes it easy' on the programmer
> to provide a broad configuration interface, but I'm fairly convinced
> that this is often not a good thing.

Ok. I don't disagree with you now that you've explained your point better.

>>>> 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.
>    Come on, the way we support remote users is almost always:
>     Please send us a reproducible test case

Sometimes yes, but often too we ask them to specify -d at the command 
line to figure out why they have just "null" appearing on stdout.

>    If they have integrated the application into a larger app then
> they are Java savy and they can be asked to modify source.  Look
> I'm not trying to say that Logging is useless just that it is
> another example of something I would rather not introduce an
> external dependency to provide.

This is a fair argument against the configuration classes, but not 
against the logging classes. There is a strong justification for logging 
in supporting users and as a development aid.

We would prefer not to remove configuration as a dependency, but I think 
we could do it as a compromise if you are prepared to accept logging as 
a dependency.


>    As I said that is currently done through the UserAgent class.
> The basic point I was making is that in order to support the GUI we
> need something a bit higher level than logging, as long as Batik
> needs that to support interactive contexts we can use it where
> FOP uses logging.

So you can simply turn off logging for the interactive use case and use 
something else, which is specific to Batik and therefore won't need to 
live in xml-commons.

>> You may be right here, but your earlier arguments are not related IMO.
>    No they weren't intended to be.  This is a separate piece of
> commentary on the proposal.


>>>> 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.
>    So what are you going to be putting in all the extra copies of?
>     <blah>/source/java/org/apache/xmlgraphics
>    I consider those to be 'empty directories', you need one copy
> of them but you don't need 7-8 copies of them.

I think I misunderstood this part of the debate. Sorry for any confusion.


>    What helps understanding is good documentation.



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