[Fwd: Re: development status]

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

  Fops,

This forwarded message is a response to Nicola which was accidentally 
sent to him only. Since I sent it the notes I refer to have been 
installed in the CVS.

Peter

  Nicola,

Most of the design docs I have prepared have been noted on this list in 
the past few months. Real Soon Now, those notes will be available as 
part of the documentation on the CVS trunk, courtesy of Arved, who will 
also apply my updates. At the same time, Keiron's overall design notes, 
htmlified by Cyril Rognon, will be merged into the documentation. Both 
will be under the "NEW DESIGN" menu, with my notes under "ALT DESIGN", 
and Keiron's notes under "Understanding."

If you mean by "framework" the scaffolding surrounding and giving access 
to the core, I have made few changes. I have changed Options because I 
found the command line and config file handling inconvenient for my own 
testing. Apart from that, all my changes are to the internal 
configuration of the core, i.e., the FO->Layout->Area transformations.

I agree with what I understand to be Keiron's position on this: the core 
is inherently tightly coupled, and presents a critical set of unresolved 
design issues to developers. I'm one of those working in there, and the 
work is far from complete. The only internal plumbing that I have so far 
done is to isolate the fo parsing from the fo tree building by providing 
a buffered single stream of events (currently XMLEvent objects, but 
better called SAXEvents) to the fo tree builder. That, at least, is one 
point at which the outside world might usefully intrude. However, I 
intend to use the same model for communication between the core 
components, defining FOTreeEvents for communication with Layout, and 
FOTreeRequests for feeback, and similar communication for the Area tree.

As it happens, such a definition could be used by the structure 
renderers, but that was not the primary purpose. Nor was it the primary 
purpose of isolating the fo parsing to allow for external intrusions. 
The main goals of all of my attempts to break the process into stages 
with tightly constrained communication are classical goals of 
modularisation: greater comprehensibility and damage control. This is a 
bitch of a spec (with all due respect to the authors, whose 
psychological health must have been severely tested by the ordeal), 
dealing with a notoriously difficult area. Developers and maintainers 
need all the help need all the help we can get in gaining and holding an 
understanding of the nature of particular problems and the methods of 
their solution.

At the moment, as I see it, there are still important unresolved issues 
with properties, layout is a fuzzy cloud, and there is a big question 
mark after the area tree. I do not believe that to be an exaggeration, 
and I do not intend it as any criticism of the great work that has 
already been done. It's just an indication of the degree of difficulty. 
More core! Muzzle the Bitch!

Peter


Nicola Ken Barozzi wrote:

>From: "Peter B. West" 
>
>>Nicola Ken Barozzi wrote:
>>
>>>Don't get me wrong, maybe I don't understand something, but still I'm
>>>
>very
>
>>>puzzled.
>>>
>>Nicola,
>>
>>Your criticism here distresses me somewhat.  How is anyone without
>>commit access able to branch the code?  I have been active on this list
>>for twelve months or more, so your not knowing of my effort reflects the
>>fact that you have recently joined.
>>
>
>Sorry, I didn't know.
>I still think that it's strange that the redesign effort is done outside of
>FOP CVS, but now it's clear to me that you didn't have another possibility.
>It's some month's I've been on this list, and my longer experience on other
>lists made me wonder about the current status of FOP. I thank you for taking
>your time to explain.
>
>Since I would like to give a hand if possible, could you please give me
>insight on how you've redesigned the framework, or some reference to
>available material?
>It would be great.
>






---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org