--- Victor Mote <[EMAIL PROTECTED]> wrote: > 1. 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.
+1 Your direction of where you want the processing logic to be--away from the non-apps packages and into apps, is the exact *opposite* of where I want things to be headed! Still, I don't think you should be hobbled by needing to be worried about multithreading issues at this time--come out with your best design as-is. Multithreading, to my limited brain, appears overrated for FOP. For single-CPU processing, multithreading AFAIK isn't going to help. For multiple-CPU, lotsa-reports-getting-generated-every-minute, that is where Cocoon and/or Servlet Containers kick in, and it is *they* who will do the multithreading, correct? (Would they even *want* us to do multithreading? I don't know. If both FOP and those services which call FOP do multithreading, that might have a detrimental impact.) > > 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 Doesn't FOTreeBuilder pipe messages to area tree processing? > 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. I wouldn't make a commitment at this time that no object from most packages needs referencing to another. To accomplish this goal--no area or rendering classes needing layout classes, etc.--you may need to rip out so much functionality into the control classes, make private variables public for control to access, etc. That will cause spaghetti code and code bloat. There goes the elegance! (1) and (2) are noble goals to be strived for, but not to the point of giving the Control classes inordinate access to the member variables/functions of all the packages. But I *highly* encourage better judgments, i.e. the other committers, to weigh in on this. > 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. > -1 (as stated). I think an AbstractLayoutStrategy should not have anything to do with the Control, the Control should be the same for all LayoutStrategies. The latter is of most value to the user--this LS prints better, this one prints faster, etc., etc.--not this LS-CS method doesn't involve the FOTreeBuilder knowing about Area Tree creation, while this LS-CS method does, etc. That's irrelevant to the user. Multiple, pluggable LayoutStrategies work best when there is a predefined begin and end to them within the application. Remember that they may also encapsulate the rendering portion (far right end), so Control (far left end) is the *only* thing currently we can keep constant between the multiple layout strategies. (As we standardize more, perhaps we can even pull out FO Tree Building creation of our the LayoutStrategies as well.) However, from (2) above, if your control classes get so much into the "innards" of each of the packages, now you have to bring the control classes into the LayoutStrategies. That's my current concern. > 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. > > +0. By the time 1-3 are done, we may be very advanced with 1.0, so even you may not agree with going back and retrofitting the 0.20 version (i.e. you'll be able to test your fonts on trunk, etc.). But if it helps you, go ahead. Glen __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
