Hello all, I'm still sifting through all the core code to determine the best way to develop the new library. John-Mark has generously provided a rough draft here: http://source.netsurf-browser.org/trunk/netsurf/Docs/ideas/render-library.txt?revision=4536&view=markup&pathrev=4536
We were discussing this on IRC and there are definitely a few concerns about functionality that could use some input. Here are my primary concerns: -- How do we handle embedded objects (<frame>, <object>, et al)? The client will fetch the page data and pass it to the library for parsing, but if the page contains frames it will require special handling (i.e. more widgets/drawing). We need to determine the sanest way to handle this situation. Perhaps the context should contain basic frame data (dimensions, etc) to allow the client to prepare his plotting canvas. Alternatively, this might be possible through the fetch callback, since the client handles its own data fetching. Perhaps we tell the client "you are fetching a page within a frame" and so he creates the necessary widgets at this time. Anyone have any brilliantly simplistic solutions? -- Where do we divide the current fetching implementation? I've been looking at this code because--all though the client should be fetching his own data--it seems like a lot of it would be necessary in the library. Could we just provide documentation and examples for struct scheme_fetcher_s (the fetch vtable) and let the client handle fetching that way? There would still be some dependencies to work out, but I think I could come up with a working solution. I'm not certain if we're looking for more simplicity or if that would be acceptable. Does anyone has any more elegant or simple solutions? I'm sure there are plenty of other things to be concerned about, but fetching callbacks are where I want to start because that will help me separate the library from NetSurf dependencies more quickly. If anyone has any other concerns, feel free to post them here. Sean
