On 21.07.2003 16:48:30 Victor Mote wrote:
> 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 :

It is still a mystery to me how you will port the old layout over but if
you see a way then go on.

BTW, nobody should be blocked by anything. I think it's better to
continually try to improve the redesign than to wait until some
particular thing is available (namely the new API or an Avalon
infrastructure). ATM, I can't invest as much time in FOP as I would like.
I'm currently doing a few things in the PostScript area that I will
commit soon but that's about it.

So, if anyone has time to work on the redesign then please do so. Just
don't forget Peter's branch. I'd like him to be able to join the
redesign development so we can keep focus.

> 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.

Hehe, no code ownership in open source. Again, don't allow yourself to
be blocked. If I express my wishes but am unable to put them to reality,
then ignore me. I have enough opportunity to include my ideas when I
have time. Blocking ourselves is the worst thing we can do ATM. If we
can show progress to the outside it will likely attract others.

> 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.

+1, if it brings the redesign forward. We have time to sort out these
things later.

> 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.

+1 but with the request that the guys with intimate knowledge about
properties and such keep an eye on it.

> 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.

Choice is always a good thing. It also provides room for experimentation.
So +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.

+1. You have been warned. :-) Good luck!

Well, I still think it would be better to separate some core utility
packages (fonts, pdf lib, svg-support...) so they could be reused in the
maintenance branch to accomplish the same. But if you think you can do
it, then do so.

> 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.

A "very" big chuck of work!

Jeremias Maerki


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

Reply via email to