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

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

> 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

> 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

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

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.


Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

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

Reply via email to