Core browser functionality
As you will all no doubt have noticed I have been splitting the browsers core functionality out from the front ends. The evantual aim of this work is to be in a position to have a browser library around which frontends can implement a browser suitable for their platform. The functionality falls broadly into these catagories: 1) library type functionality which each frontend can use to perform actions (like nsurl for handling urls and message code for handling internationalised strings) which is mainly provided in the utils directory. 2) Core browser functionality which provides everything from the fetchers to the renderer. 3) Operations the core code requires the frontend provide. These are accessed through an operations table which is currently initialised as part of gui_init() 4) Frontend code. My work so far has mainly been in the third area, but I am considering all but the frontend code in this discussion. I would like to start moving functionality out of the netsurf project and into a core library. I think I have progressed the refactoring work far enough that this is a useful thing to start. To be clear this is *purely* a reorganisation of code. The new library would remain licenced as now (GPL v2+openssl exception, unlike our other libraries which are MIT) and all functionality would remain unafected. The new library would use the core buildsystem however and be built as part of the CI system. The aim here is to have a clear identifiable boundary between what is frontend code (which will remian in the netsurf project as now) and what is core browser. This move would emphaticaly *not* be an instant change, more a gradual movement of functionality as it becomes clear where it belongs. My first addition would probably be to move the gui_factory operation table functionality and cause it to be used for the ns_register() very early in all the frontends main() which should remove some of teh issues ChrisY has experienced as fallout from my rcent refactors. I want to get input on this from everyone, especailly from Chris and Steve who have put up with my breaking their frontends with my refactors and with whom I do not get to communicate with a great deal on these things. If we decide this split is a good idea I want to decide the library name as well. If we follow the existing netsurf support library convention it would be called libns and all exported functions would be prefixed with ns_ This name fits reasonably well except it is a bit close to cocoa library naming where everything is prefixed with NS (for nextstep), This does not conflict (as nsurl etc. currently show) but might be confusing? Other options are libnscore and libnsbrowser. However please remember we prefix all exported functions with that name so nscore_ and nsbrowser_ are a bit long. e.g. nsurl_ctreate() becomes nscore_url_create() This is intended as a discussion start, if you are a current committer please do comment! -- Regards Vincent
Re: Core browser functionality
On Fri, 9 May 2014 11:44:15 +0100, Vincent Sanders wrote: My first addition would probably be to move the gui_factory operation table functionality and cause it to be used for the ns_register() very early in all the frontends main() which should remove some of teh issues ChrisY has experienced as fallout from my rcent refactors. I don't know if you saw my other note, but doing the registration early has stoped the crashing, but it still hangs in the vmkpath function. I haven't had chance to investigate further, but it looks like there might be something wrong in that function as well as the issue of the operations table. When I soft reboot after it hangs everything starts crashing, so I suspect it's trashing memory. I want to get input on this from everyone, especailly from Chris and Steve who have put up with my breaking their frontends with my refactors and with whom I do not get to communicate with a great deal on these things. I have no real opinion provided it doesn't break anything. :) I can see it being mildly annoying having to build the library and then the frontend when making/testing changes in the core, but a script can sort that out. If we decide this split is a good idea I want to decide the library name as well. If we follow the existing netsurf support library convention it would be called libns and all exported functions would be prefixed with ns_ This name fits reasonably well except it is a bit close to cocoa library naming where everything is prefixed with NS (for nextstep), This does not conflict (as nsurl etc. currently show) but might be confusing? Doesn't affect me, ergo libns is fine :) Chris
Re: Core browser functionality
On 09/05/14 11:44, Vincent Sanders wrote: I would like to start moving functionality out of the netsurf project and into a core library. I think I have progressed the refactoring work far enough that this is a useful thing to start. Yes, sounds good. To be clear this is *purely* a reorganisation of code. The new library would remain licenced as now (GPL v2+openssl exception, unlike our other libraries which are MIT) and all functionality would remain unafected. That's fine. The new library would use the core buildsystem however and be built as part of the CI system. Good. I believe we also aim to make NetSurf itself use the core build system before the next release, so we will only have one build system to maintain. The aim here is to have a clear identifiable boundary between what is frontend code (which will remian in the netsurf project as now) and what is core browser. Is the goal of this library simply to produce a well defined interface between NetSurf core and NetSurf front ends? Or is the aim to produce a browser rendering engine library, that other projects unrelated to NetSurf (e.g. a mail user agent) can use? If it's just the former, we could do it as a lib directory in the main NetSurf repo, and when you build NS it would first build libns, then NetSurf, linking it with libns. Which would simplify working on it a little, wrt Chris Young's comments. If we decide this split is a good idea I want to decide the library name as well. If we follow the existing netsurf support library convention it would be called libns and all exported functions would be prefixed with ns_ If the aim is just a clear interface between core and front end, then libns is fine. I prefer a short namespace. If it's to be a browser rendering engine library, then perhaps a non-ns name would be appropriate.
