Hi Thomas,
thanks for clearing up the points I raised. What you are saying is now a
lot clearer to me.
Thomas DeWeese wrote:
<snip/>
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.
<snip/>
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.
OK.
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.
<snip/>
What helps understanding is good documentation.
Agreed.
Chris
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
