RE: FOP ~ PropertyList search gives linear performance (FROM:fop-user)

[Victor Mote <vi...@outfitr.com>]

John Austin wrote:

> I just spent a while trying to understand PropertyList
> and PropertyListBuilder and found out that I need to
> understand Property and Property.Maker as well. I think
> I am going to have to help with this part of the project
> but it is going to take a while.

Yes, this stuff is a little hard to follow.

> I offered (off-line) to look merging the Alt-Design code
> in to the main branch but I suspect that there are some
> different directions associated with this. Perhaps this
> is the reason it has not been done so far. I am still willing
> to work on this but I don't want to walk in to a firefight.

FWIW, I don't think there is really a firefight. Our discussions are usually
at least robust, maybe even rowdy, but AFAICT, there is a large amount of
mutual respect. That said, we *are* still trying to sort out some design
issues. We currently have three lines of development, and I have made my
initial focus an effort to try to get that winnowed down to one as quickly
as possible. One of the three is Peter's alt-design. Here is a quick
summary, as I understand it (Peter please correct these if wrong -- I'm not
trying to misstate your case):
1. improved property handling
2. pull-parsing instead of an FO Tree (but with some data stored in memory)
3. a different layout approach

Re #1: there is general agreement that this can be improved, and performance
is only one aspect of this. As you have already found, readability is an
issue as well. Now that we have the FO Tree stuff in trunk isolated (kind
of), we can begin thinking of the FO Tree as a service or a separate
product. IOW, it can have its own API "contract" with the rest of FOP. As
long as the API remains constant, we can change the mechanical aspects
behind it without breaking anything else. Thus my comments yesterday about
changing the API first.

Re #2: this is the one that I don't yet understand. Peter and I had a thread
about six months ago that tried to resolve this, and I think he will respond
to this when he has time.

Re #3: we have now implemented LayoutStrategy, which means that alternative
layout systems can at least theoretically be dropped into FOP. See
subsequent announcement for more information on this aspect.

The real issue for you John is whether #1 can be separated from #2 within
the alt-design stuff. I don't know the answer, since properties to me means
"FO Tree" and means something else in alt-design. I would personally be very
glad to have you look at the whole thing, being confined neither to the
status quo nor to Peter's work (but considering both), and make a
recommendation. One of the reasons for the FO Tree isolation work was to
make issues like this easier to address -- except for the FO Tree API issues
(which should be resolved first), you don't have to worry at all about
breaking layout or renderers.

Victor Mote

RE: FOP ~ PropertyList search gives linear performance (FROM:fop-user)

[Victor Mote <vi...@outfitr.com>]

Peter B. West wrote:

> > 1. improved property handling
> > 2. pull-parsing instead of an FO Tree (but with some data
> stored in memory)
> > 3. a different layout approach

...

> > Re #2: this is the one that I don't yet understand. Peter and I
> had a thread
> > about six months ago that tried to resolve this, and I think he
> will respond
> > to this when he has time.
>
> That thread was as much (or more) about #3, IIRC.  Yes, alt.design uses
> pull parsing, but it definitely builds a tree, using the Tree and
> related classes that I wrote when I first became involved.  The major
> difference is not with pull parsing (although it necessitates a
> different approach for extensions), but with the layout dependencies
> that I see as unavoidable for property resolution. (See below.)

OK. I am using "FO Tree" in a specific sense, i.e. the FOP FO Tree. I think
you are referring to a different data structure of your own making. The
point is that if John or anyone else wants to help integrate your work into
the trunk line of development, either 1) the existing FOP FO Tree has to be
scrapped, or 2) your Tree structure must exist in parallel with the existing
FOP FO Tree. Is that not correct?

> > Re #3: we have now implemented LayoutStrategy, which means that
> alternative
> > layout systems can at least theoretically be dropped into FOP. See
> > subsequent announcement for more information on this aspect.
>
> And thereby hangs a tale.  I started (FOP)life as a believer in the
> separation of property resolution and layout as sequential stages, as
> the Rec seems to state very clearly.  In the process of trying to code
> the property resolution, it gradually dawned on me that such separation
> cannot occur.  Going back to the Rec, I found the editors' escape
> clause.  Dialogue with the editors has since confirmed that they were
> aware of the layout dependency for property resolution.

I just spent some time reviewing some of the doc in alt.design again. I
looked for but did not see documentation about your thought process here
(i.e. why FO Tree should be abandoned in favor of your system). I know it is
embedded in the archives, but do you have a well-written summary of the
whole thing somewhere that I could use to refresh my memory? There is a lot
of "what" in the doc -- if you could add some "why" it would be a big help.

> The question for me was, "Do I kludge around this dependency and
> introduce back-door methods of solving the layout feedback issues for
> property resolution, or do I look for a design that is up-front about
> this?"  I was engaged in that search.  The process will not be simple
> and clean, because the problem is not.  I'll settle for coherency,
> robustness and comprehensibility, if I can achieve them.

I will freely admit that I don't know as much about this problem as you do.
Your position is that the devil in the details makes FOP's high-level design
a "kludge". Since I am (regrettably and much to my frustration) knee-deep in
the high-level design issues, I *really, really* want to make sure that we
are on the right track with them. IOW, lets try again to resolve this, if
you have time.

Victor Mote

Re: FOP ~ PropertyList search gives linear performance (FROM:fop-user)

["Peter B. West" <pb...@powerup.com.au>]

Victor Mote wrote:
> John Austin wrote:
> 
>>I offered (off-line) to look merging the Alt-Design code
>>in to the main branch but I suspect that there are some
>>different directions associated with this. Perhaps this
>>is the reason it has not been done so far. I am still willing
>>to work on this but I don't want to walk in to a firefight.
> 
> 
> FWIW, I don't think there is really a firefight. Our discussions are usually
> at least robust, maybe even rowdy, but AFAICT, there is a large amount of
> mutual respect. That said, we *are* still trying to sort out some design
> issues. We currently have three lines of development, and I have made my
> initial focus an effort to try to get that winnowed down to one as quickly
> as possible. One of the three is Peter's alt-design. Here is a quick
> summary, as I understand it (Peter please correct these if wrong -- I'm not
> trying to misstate your case):
> 1. improved property handling
> 2. pull-parsing instead of an FO Tree (but with some data stored in memory)
> 3. a different layout approach
> 
> Re #1: there is general agreement that this can be improved, and performance
> is only one aspect of this. As you have already found, readability is an
> issue as well. Now that we have the FO Tree stuff in trunk isolated (kind
> of), we can begin thinking of the FO Tree as a service or a separate
> product. IOW, it can have its own API "contract" with the rest of FOP. As
> long as the API remains constant, we can change the mechanical aspects
> behind it without breaking anything else. Thus my comments yesterday about
> changing the API first.
> 
> Re #2: this is the one that I don't yet understand. Peter and I had a thread
> about six months ago that tried to resolve this, and I think he will respond
> to this when he has time.

That thread was as much (or more) about #3, IIRC.  Yes, alt.design uses 
pull parsing, but it definitely builds a tree, using the Tree and 
related classes that I wrote when I first became involved.  The major 
difference is not with pull parsing (although it necessitates a 
different approach for extensions), but with the layout dependencies 
that I see as unavoidable for property resolution. (See below.)

> Re #3: we have now implemented LayoutStrategy, which means that alternative
> layout systems can at least theoretically be dropped into FOP. See
> subsequent announcement for more information on this aspect.

And thereby hangs a tale.  I started (FOP)life as a believer in the 
separation of property resolution and layout as sequential stages, as 
the Rec seems to state very clearly.  In the process of trying to code 
the property resolution, it gradually dawned on me that such separation 
cannot occur.  Going back to the Rec, I found the editors' escape 
clause.  Dialogue with the editors has since confirmed that they were 
aware of the layout dependency for property resolution.

The question for me was, "Do I kludge around this dependency and 
introduce back-door methods of solving the layout feedback issues for 
property resolution, or do I look for a design that is up-front about 
this?"  I was engaged in that search.  The process will not be simple 
and clean, because the problem is not.  I'll settle for coherency, 
robustness and comprehensibility, if I can achieve them.

> The real issue for you John is whether #1 can be separated from #2 within
> the alt-design stuff. I don't know the answer, since properties to me means
> "FO Tree" and means something else in alt-design. I would personally be very
> glad to have you look at the whole thing, being confined neither to the
> status quo nor to Peter's work (but considering both), and make a
> recommendation. One of the reasons for the FO Tree isolation work was to
> make issues like this easier to address -- except for the FO Tree API issues
> (which should be resolved first), you don't have to worry at all about
> breaking layout or renderers.

Peter
-- 
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Re: FOP ~ PropertyList search gives linear performance (FROM:fop-user)

["Peter B. West" <pb...@powerup.com.au>]

John Austin wrote:
> On Wed, 2003-11-19 at 15:22, Victor Mote wrote:
> 
>>John Austin wrote:
> 
> 
>>>to work on this but I don't want to walk in to a firefight.
>>
>>FWIW, I don't think there is really a firefight. Our discussions are usually
>>at least robust, maybe even rowdy, but AFAICT, there is a large amount of
>>mutual respect. That said, we *are* still trying to sort out some design
> 
> 
> Ah yes! The old vigorous and spirited exchange of views.

AKA a full and frank exchange of views.

Peter
-- 
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

RE: FOP ~ PropertyList search gives linear performance (FROM:fop-user)

[John Austin <jw...@sympatico.ca>]

On Wed, 2003-11-19 at 15:22, Victor Mote wrote:
> John Austin wrote:

> > to work on this but I don't want to walk in to a firefight.
> 
> FWIW, I don't think there is really a firefight. Our discussions are usually
> at least robust, maybe even rowdy, but AFAICT, there is a large amount of
> mutual respect. That said, we *are* still trying to sort out some design

Ah yes! The old vigorous and spirited exchange of views.
-- 
John Austin <jw...@sympatico.ca>