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 11:44:35 GMT
> On 11.08.2005 02:34:35 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).

Jeremias Maerki wrote:

> Ok, we disagree then. It probably doesn't help either to say that
> certain things in Batik similar to that topic make my head spin, too.

    It's not a matter of making my head spin, I just don't like it.
I understand the attraction it has, I just don't like it's model,
this only makes it harder to accept as a dependency.

    Also it's worth noting that the oddities of Batik don't add external

> Fact is that both Batik and FOP are stable products, having lost their
> hype-factor, and they are too small or too specialized to attract many
> corporate supporters. We have to fight to make us attractive. 

     Well, my personal suspicion for Batik is that there aren't
enough itches.  It basically does it's job too well, SVG isn't
people's main interest and it does all the basic stuff really
well so for 99% of users they just drop it in and it works.

> It must be as easy as possible for newbies to jump in. So we have to 
> find solutions for that. Somehow. Both FOP and Batik IMHO suffer 
> from the "big blob of code" problem. I don't know the ideal solution 
> to that problem, yet. Good ideas are always welcome.

>>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.
> That's mostly because nobody's done the documentation, yet.

    The code/interfaces should provide most of the documentation.

>>    The problem is that I don't care how big or small a dependency is
>>once the dependency is there it causes problems.
> Dependency: The great FUD-word. Sorry for being sarcastic.

    Why is it FUD?  I'm a bit annoyed that you are accusing me of
spreading FUD.  Batik has had quite a bit of trouble with dependencies
requiring our developers to drop everything to sort out an issue.
It is quite disruptive, often the fix isn't very good because the
developer is racing to resolve an issue and hasn't planned the
update/change and doesn't have the time to understand what changes
have taken place in the other library.

> pdf-transcoder.jar contains commons-logging, commons-io and
> avalon-framework repackaged in the JAR. Batik didn't seem to have a
> problem with that until now. 

    Actually that's not true, I was really annoyed when those popped up
and I did much of the initial work to bury them in the PDF transcoder
Jar.  I'll also say that as long as the dependency stays limited to that
I'll be satisfied.  What I don't want is that the codecs and the
Graphics2D implementations (core components of Batik) start acquiring
these dependencies.  This is a serious concern since most people will
view these classes as a common dependency of xmlgraphics-commons.

> And that's the whole point: People who have
> problems with additional JARs (and that's probably the main problem) can
> get a repackaged JAR if need be. That's what I've done for
> pdf-transcoder.jar. That's what Xalan-J did in their latest release,
> they repackaged Apache BCEL and Apache Regexp in their xalan.jar.
> Dependencies are nothing more than Java classes that are not directly
> coming from the same project. 

    They are more.  First because of Ruby, second because a client
may already be using an incompatible version of the library, forcing
the person using the 'older' version to make an unplanned/unwanted
upgrade to the component.  If Fop/Batik was the only one using the
dependency then I would agree, but this isn't the case.

> Like we in FOP depend on Batik and have been bitten a number of times 
> by interface changes. Things like that happen. That's why people and 
> projects should talk to each other.

    So you closely track development of Excalaber and Commons logging
and I/O?  Do you want to?  I know that I don't.

> That is also one of the reasons behind XML Graphics Commons.
> FOP could have continued with its own SVG implementation. But that would
> have made no sense. FOP is extremely happy for the dependency on Batik
> because of the benefits!

   Sure but Batik provides _loads_ of functionality.  It's a
balancing act: How much do I gain by adding this dependency?
Is the dependency stable? Am I going to have to/want to rip it
out in a year or two to move to something else?

>>>I don't see how logging disturbs operation in interactive contexts. 
>>    It doesn't necessarily disturb it but it doesn't help either.
> It can help the developer. Logging is easily turned off entirely for an
> interactive application. Almost no performance penalty for logging if a
> few very simple rules are followed.

   Like wrapping every call to log with a runtime check? :(
You can do that for System.err as well ;)

> But adding and removing System.err/outs all the time is not really a good
> solution. There are a few things you can't do with them:
> - You can't turn on logging through a configuration file in a production
> environment to investigate strange behaviour in a server application.
> - You can't just tell people with a problem to specify "-d" on the
> command-line do we get more helpful information on what is probably
> going on inside the code. This makes helping people a lot easier.
> - Switching on a certain group of logging statements for a special task
> at hand while developing. It makes me so much more productive.

  I didn't try and say that logging was bad, I just don't think
it's worth an external dependency.

  In my experience I have usually had to first look at the code
to figure out what logging I needed to turn on, and second
almost always had to add additional logging to track the problem.
Then at least for graphics (which I suspect tend to be called
several orders of magnitude more than most things) I have to
really remove the extra logging or put it in a  totally separate
log category/subcategory (and a separate conditional) since
it would make it impossible to track other issues and/or impact
performance. By which time just adding/removing the // on System.err is
looking  pretty good to me (especially if you need to pass or gain
access to a log object, as opposed to having global loggers, I'm not
100% certain which FOP uses).

>>Now there are potentially non-interactive applications
>>for Batik components (the transcoders mostly) but right now they
>>handle logging/notification through the UserAgent classes.
> Yes, but the name "UserAgent" implies that this is used for interaction
> with the user. Who interacts with the developer, giving him the
> information he needs?

    The UserAgent, it is the embodiment of the user in the software.
Some users just want more/different information than others.
A developer is just a very detail oriented user ;)

    IMO there can just be a 'log' method on the UserAgent the
application can forward this to a logging implementation that
does 'smart things' or it can print it with System.err or it
can just eat it, or it can forward it to the current applications
logging system.


> So. Do we all agree that I should change the suggested directory tree to
> show a combined package structure, not a separate one?

    This is my preference.

> Another thing I can do (if noone objects) while moving code from FOP to
> Commons is to remove Commons Logging from certain library parts (PDF lib,
> for example) which are not crucial. Maybe even all of it. That should be
> possible without too much backfire. I'd kill everybody who'd want to
> deprive me of the use of a logging facility in FOP's layout engine,
> though. :-) I'd like to keep the dependency on Commons IO. I can offer
> to do the repackaging work in the Ant builds.

    This also works for me.

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