On Wed, 2 Jul 2008, Sean Fox wrote:

Currently the rendering code is designed as a box tree, which I think would be an effective design if it's moved to a library. Does everyone agree on this aspect or are there other approaches that we should consider?

I think the box tree should be wholly hidden from the client.

Last week we also discussed whether the library should provide GUI functionality or if the caller should be left to provide his own functions to display the resulting structure (box-tree).

I think the plotting interface is the natural point to divide things. The client can register a plotter to draw content. There'll need to be some kind of API to give the library information about mouse position, etc. (e.g. for dynamic styling changes).

Do we provide the fetch functions to obtain the html to process or should we have the lib caller obtain the data himself and pass a reference to it?

The latter. The fetch stuff can remain separate, I guess. That said, there'll need to be an API which allows the client to provide a way for the library to fetch data (e.g. stylesheets). Some consideration would need to be given to whether such an API is synchronous or asynchronous.

Even if the lib caller obtains the html data himself, how do we handle <img> tags? Does our lib fetch those?

See above :)

On the subject of images, the caller would have to provide support for that. I was thinking the box would be flagged as containing an image, which the caller could then fetch and process, but I'm not even certain how the current implementation handles this.

Assuming that the library has a way to fetch external resources used by the page, then all the image processing can be handled by the library.

All the above basically means that the content management bits of content/, css/, render/, and image/ get shifted into a library with a sane API. css/ will eventually become redundant, of course, but that shouldn't matter for the moment (it's pretty self-contained and only used by render/, iirc).

There'll be a few other unforeseen dependencies (e.g. things in utils/ or desktop/) but I think that covers most of it.


J.

Reply via email to