Architecture proposal

[Peter Harvey <peter a harvey gmail com>]

Hello all,

I'm going to outline a possible change in the architecture of Epiphany.
It's relatively minor, but should make writing extensions and general
maintenance easier. I'll pick on some examples first to show how the
code operates.

     1. You have clicked on a link: the EphyWindow calls upon its
        EphyToolbar to call upon the EphyLocationAction associated with
        the GtkUIManager of the EphyWindow, which then sets each
        EphyLocationEntry widget.
     2. You have entered a location: the EphyLocationAction emits a
        signal via its EphyLink interface to inform the EphyToolbar,
        which in turn inform uses its EphyLink interface to inform the
        EphyWindow.
     3. You are loading a page: the EphyWindow calls upon EphyToolbar to
        "sync chrome", which changes the sensitivity of actions like
        Stop.

Routing calls through EphyToolbar has some problems:
      * it's not accessible to extensions - they can't add their own
        widgets that respond to "loading", etc.
      * it seems to be based around the idea that all such actions are
        on the toolbar, which feels conceptually wrong.
      * it's complex

My replacement solution would be:
      * have the current status of an EphyTab exposed through GObject
        properties like "loading" and "address".
      * have EphyWindow mirror the properties of the currently selected
        EphyTab.
      * each action that relates to the EphyWindow will respond to
        changes in those properties by become sensitive, changing text,
        etc. 
Importantly, this kind of system is clean and easily extensible. If your
"check spelling mistakes on this page" extension only works when the
file is fully downloaded, you can make your action sensitive/insensitive
appropriately. If you want to write an extension to retrieve Google
PageRank information, or to provide a "translate" menu based on the
encoding of a file, you can.

We can also review the usefulness of the EphyLink interface; it seems to
be useful in only some circumstances, as the endpoint in any chain of
EphyLinks is always an EphyWindow.

These are just my ideas, and would like to see them either shot down or
turned into a rough spec of where Epiphany can go to next. If we do this
right it shouldn't take much effort - just all code follows a certain
set of rules for implementation, and we slowly migrate all the code
over. It would involve significant breakage of the development branch of
Epiphany for a while, but would give some good results I think.

Finally, I would like to see some changes to the base system.
Particularly, exposing download functionality of libnecko via a DBUS
interface. This would involve having Epiphany run in a daemon mode. The
basic request would be "download http://blah.com/file to ~/file". We
could then replace the http method of gnomevfs with DBUS calls to
Epiphany.
     1. Application wants to access file http://blah.com/file
     2. Application calls upon GnomeVFS to access the file
     3. GnomeVFS uses a libhttp.so VFS method provided by Epiphany.
     4. This method opens a named pipe in ~/.gnome2/epiphany/tmp and
        asks Epiphany to download the file to that pipe.
     5. This method then reads from that pipe on behalf of the
        application.
The end result is a GnomeVFS method that uses the cookies, etc. of the
user's web browser to download files. This would also allow integration
with Nautilus.

Thoughts?

Regards,
Peter.