NetSurf Library Project - Open Discussion

[Sean Fox]

Hello all,

I'd like to present for discussion the subject of my GSoC application,
"extracting the core into a library."  Over the last several days,
I've discussed several possibilities and concepts with everyone in
#netsurf, and I feel like we all have some great ideas.  Here are a
few of my questions and concerns:

1. How does everyone feel about the current directory structure of the
source?  Should it be separated into a library and GUI section or
should we rely on the Makefile to compile the necessary components as
a library and leave the directory structure in tact?  We should also
consider how we intend to package NetSurf once the library is
complete.  Do we plan to distribute it as one entity or as two
separate packages?  This answer may lead to a decision regarding the
directory structure.

2. How many libraries do we intend to have?  One dev mentioned there
may be interest in having a library that fetches and parses content
and another that handles the layout and display of content.
Alternatively we could simply have one library that is kept separate
only from the platform-specific and/or GUI code.  If we create more
than one library, what are your thoughts on how to separate the
current code?

3. The use of libtool has come up as one possible method of providing
a platform-agnostic library installation.  This would add some
overhead as some scripts would be bundled with NetSurf to assist in
library installation; however it would be beneficial in that it
performs proper installation of static and shared libraries on several
platforms--it's worth noting that some systems do not support shared
libraries.  This may be a matter of deciding which platforms we want
to support and whether libtool is beneficial and/or required to
provide that support.

4. It is also my understanding that the current API could use
revising, but there have been few specifications regarding which areas
are in need.  I understand the whole system may need some tidying, but
knowing what areas are of particular concern would be beneficial.  It
is good programmatic style to tackle the ugliest, most inefficient
code first because this creates the most benefits when cleaned up.
Any of your comments are welcome.

5. One of the goals of this project, as far as I know, is to provide
these features to any other application developers who would like to
use them.  If this is the case, a decision should be made concerning
which features are a necessity in the library as opposed to features
that are simply recommended for inclusion.  This could be a decision
affecting the API, the logical structure of the code-base, and is
somewhat-related to my concerns in #2.

These are the thoughts I have in getting started, all though I'm sure
more questions will arise as we move along.  If anyone has any
concerns aside from these, please present them for open discussion
here on the mailing list.

Also, as a side-note, I'd like to point out that the comments I made
previously in #netsurf concerning the simplicity of moving the core to
a library was meant to imply that compiling the source as a library is
a trivial matter.  The code I posted to the mailing list previously
demonstrates this fact as well as providing an example of the possible
changes the Makefile will incur once this distinction is made.  This
project is really much more concerned with revising the API and
separating the code in a logical and manageable manner.  Ideally the
concerns presented here will allow us to clearly define the project's
goals and--as a result--a timeline of events that must take place to
accomplish these goals.  Your comments, concerns, questions, and
thoughts are all very welcome.

Thanks,

Sean Fox