diff options
Diffstat (limited to 'doc/Dillo.txt')
| -rw-r--r-- | doc/Dillo.txt | 43 |
1 files changed, 18 insertions, 25 deletions
diff --git a/doc/Dillo.txt b/doc/Dillo.txt index 47f89780..b9ef0513 100644 --- a/doc/Dillo.txt +++ b/doc/Dillo.txt @@ -24,30 +24,30 @@ developers. Dillo can be viewed as the sum of five main parts: 1.- Dillo Widget: A custom widget, FLTK2 based, that holds the -neccesary data structures and mechanisms for graphical rendering. +necessary data structures and mechanisms for graphical rendering. (Described in Dw*.txt, dw*.c files among the sources.) 2.- Dillo Cache: Integrated with a signal driven Input/Output engine that handles file descriptor activity, the cache acts as the main abstraction layer between rendering and networking. Every URL, whether cached or not, must be retrieved using -a_Cache_open_url (Described briefly in Cache.txt, source -contained in cache.c). - IO is described in IO.txt (recommended), source in IO/. +a_Capi_open_url (Described briefly in Cache.txt, source +contained in capi.c). + IO is described in IO.txt (recommended), source in src/IO/. 3.- The HTML parser: A streamed parser that joins the Dillo Widget and the Cache functionality to make browsing possible -(Described in HtmlParser.txt, source mainly inside html.c). +(Described in HtmlParser.txt, source mainly inside html.cc). 4.- Image processing code: The part that handles image -retrieving, decoding, caching and displaying. (Described in -Images.txt. Sources: image.c, dw_image.c, dicache.c, gif.c, +retrieval, decoding, caching and displaying. (Described in +Images.txt. Sources: image.c, dw/image.cc, dicache.c, gif.c, jpeg.c and png.c) 5.- The dpi framework: a gateway to interface the browser with external programs (Example: the bookmarks server plugin). Dpi spec: http://www.dillo.org/dpi1.html - + ------------------------- HOW IS THE PAGE RENDERED? @@ -55,34 +55,27 @@ Dpi spec: http://www.dillo.org/dpi1.html (A short description of the internal function calling process) - When the user requests a new URL, a_Interface_entry_open_url + When the user requests a new URL, a_UIcmd_open_url is queried to do the job; it calls a_Nav_push (The highest level URL dispatcher); a_Nav_push updates current browsing history and calls Nav_open_url. Nav_open_url closes all open connections by -calling a_Interface_stop and a_Interface_stop, and then calls -a_Capi_open_url wich calls a_Cache_open_url (or the dpi module if +calling a_Bw_stop_clients, and then calls +a_Capi_open_url which calls a_Cache_open_url (or the dpi module if this gateway is used). - If Cache_search hits (due to a cached url :), the client is + If Cache_entry_search hits (due to a cached url :), the client is fed with cached data, but if the URL isn't cached yet, a new CCC -(Concomitant Control Chain) is created and commited to fetch the -URL. Note that a_Cache_open_url will return the requested URL, -whether cached or not. +(Concomitant Control Chain) is created and committed to fetch the +URL. The next CCC link is dynamically assigned by examining the -URL's protocol. It can be: - - a_Http_ccc - a_File_ccc - a_About_ccc - a_Plugin_ccc (not implemented yet) - +URL's protocol. It can be a_Http_ccc or a_Dpi_ccc. - If we have a HTTP URL, a_Http_ccc will succeed, and the http + If we have an HTTP URL, a_Http_ccc will succeed, and the http module will be linked; it will create the proper HTTP query and link the IO module to submit and deliver the answer. - Note that as the Content-type of the URL is not always known + Note that as the Content-Type of the URL is not always known in advance, the answering branch decides where to dispatch it to upon HTTP header arrival. @@ -94,7 +87,7 @@ called for each tag (to parse and call the appropriate methods) and the whole page is contructed in a streamed way. Somewhere in the middle of it, resize and repaint functions are activated and idle functions draw to screen what has been -processed. +processed. (The process for images is described in Images.txt) |