As an active FOP user I have been monitoring the fop-dev list for the last 2
years or so.
The recent discussion between Victor and Peter and JÃrg's comment below seem
to highlight a difference in opinion where the project is headed.
Based on the various discussions on this list and the web site it appeared
to me that the goal for the development branch is:
a) Basic level compliance to the FO spec
b) Support for arbitrary sized documents
plus a number of sub goals.
Both of these goals appear to create really hard design problems for which
even experienced FOP developers don't have solutions to. For example the
issue of resolving property values, the dependency of the resolution on the
layout, and the special handling required for resolution in the context of
markers, seem to cause lots of design discussions without actually
converging. This indicates to me it is most likely a hard problem when,
given the quality of the people contributing, not even after a year or so an
agreed and understood design solution is forming. And property value
resolution is only a small item in the problem domain created by the XSL-FO
spec.
Personally I agree with JÃrg that the project needs working code especially
as the maintenance branch is frozen and no more releases are forthcoming
until the development branch is ready. This becomes a "very long time
between drinks" for your user base.
However, to achieve the working code may be the project goals need to be
revised downwards. May be the project should scrap the design goal of basic
level compliance and support for large documents and aim for a smaller
subset. For example: Go through the list of unsupported or incomplete
supported fo elements and properties and agree on a subset to be supported
in the next release. Keeps, auto table layout, bidi font support are some
that come to mind but I am sure there are more (or less).
Once that is agreed concentrate design and implementation discussions on
these revised goals. If it turns out that this leads to design decision
which will make other things (outside the stated goals) hard later - tough
luck that's then left to the next refactoring effort. If it leads to certain
property expressions not being supported - tough luck as well. If it leads
to markers not being done perfectly - tough luck as long as the stated goals
are achieved (this assumes perfect marker handling is not one of the goals).
Isn't that part of the 'Extreme Programming' methodology? If it's not needed
now (= not part of the project spec) don't build it in.... don't even waste
time discussing it.
Most projects go through many iterations each leading to rewrites of
significant portions of the code (eg. tomcat 3.x, 4.x, 5.x). Why should FOP
get away with only two iterations?
Manuel
----- Original Message -----
From: "J.Pietschmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 18, 2003 3:26 AM
Subject: Re: FOs and Areas
Peter B. West wrote:
> (does JÃrg work?),
Not in the archive.
>
> I know you are a long-time advocate of sticking with the codebase, and
> have been very critical of my approach, so I don't want to draw any
> unwarranted conclusions here. Does the above mean that you are
> interested in my ideas?
I've got a lot of ideas myself, perhaps too many. What the
project needs is *working* *code*.
J.Pietschmann
