Jeremias Maerki wrote:

> I'm slowly getting the impression it may be better if we really totally
> modularize FOP (splitting it up into several independently usable
> subprojects) so development is only split in the layout field which is
> the major problem-child here. But that alone would take long enough and
> I can't even imagine how much it will hurt the redesign.

You're on the right track, but I don't know that we need separate
subprojects. I am just starting to implement an idea that I have been
kicking around for several weeks. I want to create a LayoutStrategy that is
either abstract or an interface, and which can be subclassed/implemented by
each concrete strategy. We currently have two -- one in the redesign branch,
and one in the maintenance branch. The goal would be to eventually drop the
maintenance branch layout system into the redesign code as an implementation
of LayoutStrategy. It will always be a deficient implementation, but right
now it is the best one that we have (else we would be releasing code from
the trunk). This would allow us to start releasing code from the trunk, and
would unify our efforts in infrastructure, control, FO Tree, Area Tree, etc.
This is something we really should do eventually anyway, and IMO it is
better to do sooner than later.

There are three issues: 1) Some will not like this approach as it seems to
draw resources away from the redesign. I'll not reargue this issue again now
unless it is needed. In short, nothing is being done on redesign now, so how
can it possibly be hurt by anything? Also, eliminating thrashing between two
branches will help all of us find resources to work on layout redesign. 2)
Some will think that bringing the maintenance branch layout into the
redesign will reintroduce the maintenance branch problems. Obviously, this
should be avoided, and I think it can be. There are no doubt methods and
data which will need to be moved around to get the maintenance branch layout
modularized, but it seems possible. 3) It would be helpful to resolve some
of our high-level control issues before starting down this path, or at least
as part of this project. Moving control of when layout is started, when FO
trees are destroyed, etc. up to higher-level objects will be extremely
helpful in isolating these subsystems from each other and allowing multiple
layout strategies.

I see the sequence as follows:
1. Resolve design of, then implement the high-level control changes. This is
the Session / Document / Rendering Context issue discussed on the
Avalonization wiki, section entitled "Startup Concepts Proposal" at

2. Isolate the (existing redesign) layout by forcing all contact with the
layout systems to run through the LayoutStrategy. Every layout class except
the Stategy implementation becomes non-public (I think).
3. Drop in the maintenance branch layout as an implementation of
LayoutStrategy, keeping it isolated as well. Even if this effort is
unsuccessful for some reason, or the redesign layout is completed before
this can be done, steps one and two above are still needed & useful.

I really didn't want to mention any of this until it was done, but I wanted
to encourage Jeremias' train of thought. Also, coming to an agreement on
steps one and two, and completing them, makes step three much easier. If we
can reach a consensus on items 1 and 2, I'll start on them right away. I
don't think they are big tasks, but they are pervasive and design-oriented,
and I think they require your approval.

Victor Mote

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

Reply via email to