NetSurf Library Project - Open Discussion

James Bursa james at netsurf-browser.org
Tue Mar 25 04:00:24 GMT 2008


Hi Sean,

Thanks for your message. Here's my opinion on your questions:

> 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.

I think that the natural way to organise this would be to put libraries in 
separate directories in the repository as they are extracted from the current 
source. They would live along the other NetSurf sub-projects here: 
http://source.netsurf-browser.org/trunk/

libsvgtiny was just recently extracted from NetSurf in this way.

> 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?

I think that each part of the code that could be useful on its own should be a 
library. For example CSS parsing and handling could be one library (not 
layout, i.e approximately the source in css/). BMP and GIF decoders are two 
others that should be separable easily. The other image formats are already 
handled by external libraries and the code in NetSurf itself is simple (e.g. 
jpeg.c). The problem areas will be the content/ and render/ directories, 
because there are many interdependencies.

> 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.

I haven't used libtool, so I don't know of its advantages & disadvantages.

> 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.

I don't think we have any agreed goals for this project yet. We should come up 
with some specific targets. For example (in order of implementation):

1. libnetsurfcss - a library that takes some CSS source, parses it, and 
   provides structures / an API to get the data
2. libnetsurflayout - a library that takes some HTML source, and does layout 
   on it
3. libnetsurf - a library that takes a URL, fetches and converts it, and can 
   render it

The last one is the most high-level interface, that e.g. NetSurf itself would 
then use. The middle one might be used by an email client or help browser. 
The first one would be useful for CSS tools. libnetsurf would depend on 
libnetsurflayout (and others), which would depend on libnetsurfcss, etc.

These are just examples, and may be too much for the time available.

In summary I think the most manageable and beneficial way of approaching this 
project would be to:

1. choose an area of functionality in the source,
2. extract it into a library, adding or revising the API,
3. repeat.


James


-- 
James Bursa, NetSurf developer                http://www.netsurf-browser.org/



More information about the netsurf-dev mailing list