summaryrefslogtreecommitdiff
path: root/Docs/01-content
blob: 3cfc47d8679c65aaf1daf4f97c99f8a608c5bb46 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Fetching, managing, and converting content
==========================================

The modules in the content directory provide the infrastructure for fetching
data, managing it in memory, and converting it for display.

Contents
--------
The data related to each URL used by NetSurf is stored in a 'struct content'
(known as a "content"). A content contains

* a 'content type' which corresponds to the MIME type of the URL (for example
  CONTENT_HTML, CONTENT_JPEG, or CONTENT_OTHER)
* type independent data such as the URL and raw source bytes
* a union of structs for type dependent data (for example 'struct
  content_html_data')

Contents are stored in a global linked list 'content_list', also known as the
"memory cache".

The content_* functions provide a general interface for handling these
structures. They use a table of handlers to call type-specific code. For
example, content_redraw() may call html_redraw() or nsjpeg_redraw() depending on
the type of content.

Each content has a list of users. A user is a callback function which is called
when something interesting happens to the content (for example, it's ready to be
displayed). Examples of users are browser windows (of HTML contents) and HTML
contents (of JPEG contents).

Some content types may not be shared among users: an HTML content is dependent
on the width of the window, so sharing by two or more windows wouldn't work.
Thus there may be more than one content with the same URL in memory.

Creating and fetching contents
------------------------------
A high-level interface to starting the process of fetching and converting an URL
is provided by the fetchcache functions, which check the memory cache for a url
and fetch, convert, and cache it if not present.

The fetch module provides a low-level URL fetching interface.