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 10:23:54 GMT
Chris Bowditch wrote:
> Thomas DeWeese wrote:
> 
> <snip/>
> 
>>    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?

    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.

    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.

    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.

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

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

    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.

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

    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.

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

    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.

   Can't you see that we would be kidding our selves if we
really believe that the above is more 'understandable' than:

	source/java/org/apache/xmlgraphics/<blah>

    Can't you see how unless each project is built and released
independently (at least potentially) all this does is introduce
8 copies of the root of the source tree?

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

    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


Mime
View raw message