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.
No comments:
Post a Comment