Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> But I think you have some fears because you know too little of Avalon.

Well, thats nearly the core of the problem. Actually, in my case
JAXP is the ultimate cause.

We started using XSLT in a servlet using JAXP, which defines
its own facilities for dealing with problem reports (ErrorListener
and such), configuration data and various customizations. After
some struggling we successfully plumbed it into the environment.

Then there was the task to integrate FOP, which comes with yet
another set of interfaces and other stuff to deal with problem
reports and configuration data. It was to be expected that it
wouldn't be the same as JAXP, but the relevant FOP/Avalon APIs
are simply much too different from JAXP and noticable more complex.
They may be superior to JAXP, but JAXP came first.

If i learned something during some 5+ years of interface design,
it is that users get very upset if they think something should
follow a common pattern but it doesn't. If they have to do similar
things they expect to be able to do it in a similar way. Having
to learn new ways is nearly as repugnant to them as paying taxes,
even if its obvious there will be a benefit somewhere down the road.

It gets worse when developers have to tell their project managers
they'll miss a deadline because they have to figure out another
way of doing things they've already done in another context.
Managers have a tendency to miss or ignore the "another context"
part. This adds to the pressure.

> We just
> want to use a tiny part from Avalon where logging is concerned and an
> embedder will not have to learn the Avalon way if he doesn't want to.

Note that configuration is also an issue. Note further that files
are also parts of an interface, however well hidden.

I met a Batik developer at the xml/webservices conference this
week, and discussed this problem shortly as it applies to Batik
too. I hope some ideas will emerge for converging to a consistent
and easy to use interface for various kinds of processors.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to