[uzbl-dev] Request for comments: Alternative event handler system

[Dieter Plaetinck]

On Tue, 4 Aug 2009 10:18:18 +0200
Dieter Plaetinck <dieter at plaetinck.be> wrote:

> On Tue, 4 Aug 2009 09:54:07 +0200
> Robert Manea <rob.manea at googlemail.com> wrote:
> 
> > Hello,
> > 
> > as mentioned on IRC i wrote a basic implementation of an alterantive
> > handler system.
> > 
> > Currently the only way to react to events uzbl generates is to use the
> > provided handler variables, like 'load_commit_handler',
> > 'download_handler', etc.
> > 
> > This approach has some disadvantages:
> > 
> >     - It requires you to spawn a process on every event
> unless we shift more handlers to the talk_to_socket functionality.
> It's not easy (or possible) to implement socket stuff in shellscripts, but if a script is too simple to be written in something like python,
> i doubt it's gonna be a problem spawning it a few times more.
> > 
> >     - multiple actions per event require you to spawn
> >       even more processes
> chain 'talk_to_socket <foo>' 'talk_to_socket <bar>'
> > 
> >     - There is no way to use a single daemon like 
> >       application to monitor and react to all events
> do we need that?
> > 
> >     - It scales quite poorly, introducing more events
> >       exponentiates the impact of the above mentioned
> >       points
> by strategically shifting some handlers to be in a language that supports sockets and use talk_to_socket we can alleviate this problem i think
> > 
> > 
> > The basic idea of my approach to event handling is a pretty simple
> > one.
> > 
> > Whenever an event occurs in uzbl, we write a well defined
> > message/string to one of our supported interfaces.
> > 
> > There is an application listening on any of these interfaces that will
> > filter the event messages provided by uzbl and react in some way to
> > them.
> > 
> > Currently the implementation only supports writing to stdout, though
> > connecting uzbl to an event handler is a simple matter of:
> > 
> >     uzbl | event_hanlder
> > 
> > 
> > The event handler "blocking reads" from uzbl and processes the
> > messages whenever an event occurs.
> > 
> > In the shell you would use a construct like:
> > 
> >     uzbl | while read EVENT_MESSAGE; do something with
> > $EVENT_MESSAGE; done
> > 
> > 
> > The format of the event messages is:
> > 
> >     EVENT_NAME [uzbl_instance_name] event details
> > 
> > Typical event messages look like this:
> > 
> >     LOAD_COMMIT [27263008] http://uzbl.org/
> >     GEOMETRY_CHANGED [27263008] 768x1035+0+13
> >     KEYPRESS [27263008] Alt_L
> > 
> > Starting uzbl from a terminal and watching the output during a typical
> > browsing session should give you an idea of the already written event
> > messages and their contents.
> 
> This sounds all pretty cool, but once you have your "1 big(ger) process that monitors all messages", one will probably
> want to be able to use separate tools to separate tasks. (we don't want huge scripts that handle everything, do we?)
> In that case, what we've done is basically shifted the problem from uzbl to a new tool.
> 
> I've been thinking about this and the approach like what wmii (filesystem) or awesome (extensible by hooking into code) is actually nice:
> it allows you hook different scripts into your stuff with a lot of flexibility, and without performance/scalability/.. problems.
> 
> Or.. if your "big handler" is a shell script, you could probably source different other shell scripts ("plugins") and execute their provided functions.
> That may solve the fork/exec problem and still be simple and reusable.
> just thinking out loud here.
> Dieter


FYI, we've had a nice discussion about this on IRC.
It turns out there are some very interesting advantages to this approach:

- makes uzbl more modular.
- makes it possible to use whichever language you want for event handling (python, perl, bash, .. you name it) (take that, "awesome"!)
- our current keyhandling code is limited (little support for special keys and such) and rigid.
- many finegrained events (hover_over_link, keyup,keydown,..): no need for tens of handlers

So while it is still a simple concept compared to for example the virtual FS approach (and needs little LoC) it does provide a lot more flexibility.
For these reasons, I suggest we start hacking in the event-messages branch (make it able to do what we can currently do), so that this later can replace our current built-in key handler.

Dieter