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]
