I haven't researched fonts in general so I can't comment on its value or
quality. However, Victor's coding has shown itself to be pretty solid
and robust in the past. *What* Victor codes is often not my
preference, but the *way* he codes what he does is quite good. In
general, if I had a mission-critical system to build I would be
comfortable relying on him to build it.
At any rate, though, I anticipate us bringing in and modifying the code
over time, rather than keeping it as an external JAR.
Related to this is that I moved FOP from the controller-class (in use
1998-2004) to the pipeline approach[1] early last year, and still
recommend that architecture. However, I suspect the font code will be
expecting a controller-class architecture to work. Given that most
committers have been comfortable with the controller-class approach in
the past, I would be OK with it if we wanted to switch back--I can't
spend as much time anymore on FOP anyway. I remain satisfied that the
proof-of-concept worked but we have users to satisfy here... ;-)
I do have a caution to offer though: If the goal is to be rewarded for
one's efforts on FOP, make sure the architectural decisions are done so
that 18 months, 24 months down the road FOP will have a 90% market
share, even if it means there will be grumbling on the mailing lists for
the initial few months because FOP 0.20.5 is incompatible with FOP 1.0.
I personally am strong-kneed enough to handle the grumbling with the
knowledge that FOP will be ultimately very successful. Indeed, I take
it for granted that if you want a work-of-art system that puts the
competition to shame two years down the road, you have to make the
unpleasant architectural changes now to put FOP's past behind it.
For practical reasons though, we may end up needing to restore some of
the API back such as Driver. But if the team does not think long-term,
and just reacts to every individual ML complaint by adding to the API,
FOP will become unmaintainable and start to degrade. I was around in
late 2003 when FOP 1.0 had all the API's of the past--it also went down
to three active committers at that time--Victor, Joerg, and myself. Too
much to maintain, then people get turned off from the project, and,
long-term, users on the ML get confused, given the multiple ways to do
the same thing.
Glen
[1] http://marc.theaimsgroup.com/?l=fop-dev&m=106246324305040&w=2
J.Pietschmann wrote:
Vincent Hennebert wrote:
Sorry to insist, but what is your final decision? A quick summary of
the thread gives:
- Jeremias +1
- Simon +1
- Glen +0
The FOray+aXSL stuff would be used in the form of a jar file put in
the lib directory; FOray's avalon loggers would be wrapped into a JCL
adapter for now.
I'm somewhat uneasy with having an important if not essential
subsystem developed outside (unless already widely used elsewhere),
but I certainly wont veto anything which advances the project.
+0
J.Pietschmann
