xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: XML Graphics Commons: last call
Date Thu, 11 Aug 2005 14:26:51 GMT

On 11.08.2005 13:44:35 Thomas DeWeese wrote:
> > 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
> dependencies.

But possibly to the internal complexity and code base size. So be it. I
understand your argument a lot better now.

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

Yep, my big problem with Barcode4J. It's almost perfect. :-(

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

Exactly because of your generalization that any dependency automatically
causes problems. That's pure FUD. Sure, there may be problems but that's
normal in software development and hopefully, a dependency is only
introduced when it brings considerable benefit. Even there you agree as
I can see further down.

>  I'm a bit annoyed that you are accusing me of
> spreading FUD. 

I'm sorry. But it was, IMO. Just reproducing and debugging tons of
functionality again and again even though established and stable
solutions are available doesn't go well with me. But I'm sure we can do
something about your truly valid concerns. My goal: I want results now.
I still have to have some energy left to actually move (or rather copy
at the beginning) those components once we've agreed on the plan. 

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

With this argument you'd have to implement your own operating system and
your own JVM and restrict it to one platform alone. Not all problems can
be avoided, can they? It's simply part of the game and it's partly what
makes our jobs interesting. Nobody said "software developer" (or rather
"problem solver") was an easy job. I may be weird, but I like it that
way. :-)

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

Ok. But you realize this might even result into an argument for
splitting the individual components? :-) Seriously, I understand that.
Let's try to remove those dependencies as much as possible.

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

Good point. A good example in this context: Some FOP users complained
that they can't use Batik 1.6 with FOP 0.20.5. :-( The nice thing about
Avalon Framework and, so far, Commons Logging is that the changes were
always backwards-compatible.

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

Yes, I do, and yes, I want to. Not so much for Excalibur since Avalon
Framework is dead stable, but I'm a committer in Commons IO. All that's
part of the dependency deal. Same problem inside one project. Does every
committer have a good idea about every little part in a project? No,
surely not.

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


Commons Logging:
Interface: absolutely stable (almost the same as the ubiquitous Log4J),
doesn't force the actual choice of logging framework to the user, it's
easy to add custom backends without changing the calling app.
Implementation: under revision mostly because of some weird class loader
problems in very special environments.

Avalon Framework: 
Interface: absolutely stable, Implementation: absolutely stable. Every
release was fully backwards-compatible.

Commons IO:
Interface: stable now that 1.0 is available. Backwards-compatibility is
a high concern in this project.

These dependencies were not added out of the blue. There were and are
good reasons for them. But again, we can revise them for the parts we
move. Too bad I'm probably going to be the only one doing all the work
from the FOP-side. Prove me wrong, guys!

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

Sure you can. And then you have to start building a non-intrusive
configuration mechanism to switch on and off certain groups. Again. :-)

Just keep in mind, those who run server-side apps hate System.out/err!
And FOP is mostly used in this area.

So we really need to understand that all we build here must hold for
both extremes: applet-embedding and server-side service.

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

We've moved from a mix of global logging (MessageHandler which is
similar to your UserAgent) and logger passing (Avalon) to static logging
(Commons Logging). The latter emphasizes the fact that logging is mainly
for the developer and a different mechanism is needed for end-user
communication, especially in multi-threaded environments. The latter is
missing ATM. FOPpers, do you hear me? :-)

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

Doesn't mean that it has to be squeezed through the same channel. The
problem is that passing the user agent all through the system isn't the
best thing to do. We've experienced something similar with Avalon
Logging and it didn't turn out well.

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

But given the libary character of the new components you'd have to
define various levels of UserAgents (dependency management and all).
That doesn't sound very promising.

Anyway, let's hope that is moot and we can do without logging in these
basic libs.

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

Ok, let's start with that.

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


Sorry, Thomas, for being hard on you. I just want you to see our side,
too. We have two different philosophies here. I hope we can find a good
middle way. And I naively thought the "last call" would be easily waved
through after the previous discussions. Ha.

Jeremias Maerki

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