1.1 --- a/unix-phil.ms	Tue Mar 30 23:20:40 2010 +0200
     1.2 +++ b/unix-phil.ms	Sat Apr 03 10:33:33 2010 +0200
     1.3 @@ -1301,13 +1301,45 @@
     1.4  .B "Avoid captive user interfaces" .
     1.5  One could say, that uzbl, to a large extend, actually \fIis\fP
     1.6  a captive user interface.
     1.7 -But the difference to most 
     1.8 -
     1.9 +But the difference to most other web browsers is, that uzbl is only
    1.10 +the captive user interface frontend and the core of the backend.
    1.11 +Many parts of the backend are independed of uzbl.
    1.12 +Some are distributed with uzbl, for some external programs, handler scripts
    1.13 +are distributed, arbitrary additional functionality can be added if desired.
    1.14 +.PP
    1.15 +The frontend is captive \(en that is true.
    1.16 +This is okay for the task of browsing the web, as this task is only relevant
    1.17 +for humans.
    1.18 +Automated programs would \fIcrawl\fP the web.
    1.19 +That means, they read the source directly.
    1.20 +The source includes all the semantics.
    1.21 +The graphical representation is just for humans to transfer the semantics
    1.22 +more intuitively.
    1.23  
    1.24  .PP
    1.25  .B "Make every program a filter" .
    1.26 -.B "Small is beautiful
    1.27 -and
    1.28 +Graphical web browsers are almost dead ends in the chain of information flow.
    1.29 +Thus it is difficult to see what graphical web browsers should filter.
    1.30 +Graphical web browsers exist almost only for interactive use by humans.
    1.31 +The only case when one might want to automate the rendering function is
    1.32 +to generate images of rendered webpages.
    1.33 +
    1.34 +.PP
    1.35 +.B "Small is beautiful"
    1.36 +is not easy to apply to a web browser, primary because the rendering task
    1.37 +is very complex.
    1.38 +Modern web browsers will always consist of many thousand lines of code,
    1.39 +unfortunately.
    1.40 +Using the toolchest approach and wrappers can split the browser into
    1.41 +several small parts, tough.
    1.42 +.PP
    1.43 +Uzbl-core consists of about 3\,500 lines of C code.
    1.44 +The distribution includes another 3\,500 lines of Shell and Python code,
    1.45 +which are the handler scripts and plugins like a modal interface.
    1.46 +Further more, uzbl uses external tools like \fIwget\fP, \fInetcat\fP.
    1.47 +Up to this point, uzbl looks pretty neat and small.
    1.48 +The ugly part of uzbl is the web content renderer webkit.
    1.49 +Webkit consists of roughly 400\,000 (!) lines of code.
    1.50  
    1.51  .PP
    1.52  .B "Build a prototype as soon as possible" .
    1.53 @@ -1333,6 +1365,24 @@
    1.54  .LP
    1.55  broken web
    1.56  
    1.57 +.PP
    1.58 +But all functionality should be accessable at the backend too.
    1.59 +Uzbl fails here, mainly because of webkit.
    1.60 +Uzbl is not clearly separated into frontend and backend,
    1.61 +especially the render engine is not an separate building part,
    1.62 +like, for instance, the download manager is.
    1.63 +This comes from the design of webkit.
    1.64 +Webkit is not a self-standing program but a library to include.
    1.65 +This might be of need for a graphical application to avoid complexity,
    1.66 +but webkit has a lot of features included that do not belong to the
    1.67 +webpage rendering job; a browsing history is just one example.
    1.68 +.PP
    1.69 +Ideally, webkit would just render the source of a webpage into a
    1.70 +nice formated representation.
    1.71 +.PP
    1.72 +be a black box
    1.73 +
    1.74 +
    1.75  
    1.76  .NH 2
    1.77  Summary uzbl