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
