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.
