update docs a bit

and hopefully not introduce too many inaccuracies

1 files changed, 15 insertions, 22 deletions

diff --git a/doc/Dillo.txt b/doc/Dillo.txt
index 47f89780..a2c80afe 100644
--- a/doc/Dillo.txt
+++ b/doc/Dillo.txt
@@ -31,17 +31,17 @@ neccesary data structures and mechanisms for graphical rendering.
 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
@@ -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:
+URL's protocol. It can be a_Http_ccc or a_Dpi_ccc.
 
-   a_Http_ccc
-   a_File_ccc
-   a_About_ccc
-   a_Plugin_ccc (not implemented yet)
-
-
-   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.