===================================
20131206 (Friday, 06 December 2013)
===================================

The public demos for :ref:`polly` and 
:ref:`logos` were broken due to a server 
configuration problem.
And I didn't notice it because they were not listed in :ref:`demos`.

The conversion of existing renderers to plugins
will be an occasion to tidy up some historic ambiguities.

- The Kernel. 
  The object stored in `settings.SITE.ui` : is (like SITE itself) 
  a "de facto singleton". But it remains 
  an independent class/object instance 
  (and is not merged into the Site)
  because it gets created and imported only when the modules are 
  populated. Might rename it to `kernel`. 

  Until now the activities and methods of the kernel were 
  scattered across  `ui.base`, `ui.ui` and `core.kernel`. 
  Now they are all in :mod:`lino.core.kernel`.

This was easy and has no impact on user code. 
All tests pass. Commit.
It helped me to understand the following:

- My first idea was to convert the three "renderers" 
  (TextRenderer, PlainRenderer and ExtRenderer) to plugins::
  
    SITE.ui.plain_renderer -> SITE.plugins.plain_ui
    SITE.ui.ext_renderer -> SITE.plugins.extjs_ui
    SITE.ui.text_renderer -> SITE.plugins.text_ui

- But they cannot become subclasses of `ad.App` because they get
  instantiated only during Kernel startup (i.e. when the Django models
  are already populated).

- I'd call them "runtime extensions" or "kernel plugins",
  or "features".

- Note that "renderer" is the wrong name. 
  These three things are what I would call "user interfaces".
  A user interface being "a system of methods and ways to interact 
  with the user".
  But before renaming them I should rename all current 
  occurences of "ui" to "kernel".

- Not yet sure what to do with `SITE.default_renderer`

As a result, I'll leave these ideas open for the moment and 
first convert the `use_extensible` setting into a plugin.