Fellow FOP developers:

The thread I have most been wanting to work on (and that which I think is
most important to this project right now) is that of cleaning up the lines
between our various modules, and getting LayoutStrategy working, so that we
can try to integrate our one working LayoutStrategy (from maintenance
branch) into the trunk code. I have felt blocked on that thread until we get
the API and control structure fixed a bit. I woke up this morning realizing
that perhaps we can make some progress here anyway, but this definitely
requires a consensus. Please withhold judgment on the earlier items until
you see the whole picture of where I am headed. Here is what I propose :

1. A big part of what drives our thinking on the Control structures and API
is how to deal with multithreading. I had extended that (in my Control
structure ideas) to include the issues of dealing with running multiple
documents and multiple output formats. I would like to separate all of these
issues into a separate category, which for the moment, kind of belong to
Jeremias. I would like to *temporarily* view FOP as being single-threaded,
one document at a time, one output format at a time. In other words, I would
like to have permission to temporarily treat Driver as either a singleton or
a location for static constructs, which can be used to control the
interaction between the various modules, so that I can move that logic out
of the modules themselves. I would like to leave the problems of sorting
these singleton/static constructs into constructs suitable for
multithreading, etc. environments to Jeremias in his API work. It is not my
intention to "dump" this on Jeremias or to generally be lazy, but rather to
separate the two issues so that we can each proceed at our own pace. I'll
help any way I can with the other as it unfolds. By keeping all of this in
Driver, it should at least be easy to see and manage.

Here is my +1.

2. I will then proceed to clean up lines between modules. Success will be
measured by the ability to do the following things: 1) to build without
compile errors the control and fo classes, and one entry point to Layout
(for Control) by themselves (i.e. no fo classes needing layout or area
classes), and 2) to build without compile errors the control, area, fo (?)
and rendering classes  (i.e. no area or rendering classes needing layout
classes).

Here is my +1.

3. Create an AbstractLayoutStrategy class which will encapsulate the
interaction between Control and Layout. Make our redesign layout subclass
this. (This may actually get done before item 2, as it may make item 2
easier to do). This supposes that LayoutStrategy, and, by implication, the
possibility of multiple layout engines, is a good thing. Although I have
discussed this before, it has never been canvassed. Here is your chance to
agree or disagree.

Here is my +1.

4. Make the layout logic in the maintenance branch conform to the above,
subclassing the AbstractLayoutStrategy. I won't check this work into the
repository until it is complete, as it bears the risk of failing. I have
been amply warned by Joerg that this step will be difficult, maybe
impossible, but I feel obligated to try. I will either come back with 1) a
way to unify our development efforts, or 2) greater humility and greater
knowledge of layout. Neither are bad results. An affirmative vote here
implies that retaining our maintenance branch layout (at least in the short
term) is a good thing. I want to make it clear that this is not intended to
derail or distract from the new layout scheme. I believe (but acknowledge
that I am possibly wrong), that adopting this plan gets us more quickly to
the place where we can work on the new layout, and gives us many other
benefits as well. Right now, for example, I need some font work done. I
don't feel free to do it in the maintenance branch, but that is the only
branch I can use to get any output at all for my projects. Each of us has a
similar story. I would like to get to the place where one doesn't have to
feel guilty about working on other aspects of FOP, and where our support
efforts are split/duplicated.

Here is my +1.

Except for item 1, for which I have had to adjust my thinking, I think I
have presented all of the above before, but this is the first time I have
asked for a vote. The above represents a big chunk of work, and I don't want
to complete it only to find out that it isn't wanted.

Victor Mote


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

Reply via email to