I agree with the configuration in general but not with the cocoon concept. The parts like configuration, logging, etc. could help us with the functionality and the architecture.
To serialize between the Area Tree and the Renderers there are some serious problems that would get in the way: - in many cases the area tree will need to be complete before sending anything across, this defeats the whole purpose and will use a lot of memory - embedded xml will need to be parsed twice and saxified - how do we handle area tree extensions - forward references for some renderers will mean that the renderer may also need to store the whole area tree (or part thereof) on the other side of the sax events - the layout depends on the output target, for font information On 2002.03.15 16:32 Nicola Ken Barozzi wrote: > What "bugs" me in FOP currently (the famous itch to scratch ;-) , is what > drives the whole process itself. Configuration, URI resolving, logging, > and > so on. The infrastructure. <snip> > When this is in place, all the infrastructure is there, and we can > concentrate on the real FOP code. The problem is that the *real* FOP code significantly effects the way that the processing and caching works. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
