Sunday, March 6, 2011

Core-controller application design pattern

I'm very impressed by the application design pattern of wmii (my favorite window manager during last two years) and uzbl. I can describe it this way: application decoupled to two processes. Let's call them Core and Controller. Core perform some heavyweight functions and notify Controller about significant changes trough the event queue. Controller process mostly read and sequentially/asynchronously process events and send commands back to Core. Core provide low-level functionality while Controller contain high-level logic.

Why this approach is good?

First, this approach enforce better application design - as Core and Controller live in separate processes, they can't easy and instantly communicate with each other. Therefore functions must be carefully split between this two parts. Specification of events itself is a good metaphor for application design documentation.

Second, this approach allow to implement Core and Controller on different languages, most appropriate for corresponding part. Usually it mean some lower-level language for Core and some scripting language for Controller.

Third, with proper design we are able to insert additional controller between Core and Controller, in the way, similar to shell pipes. For example to redefine application behavior for particular events/group of events without the need to rewrite/patch base Controller. This approach is similar to python wsgi schema.

And now the point of this post. Web-browser and window manager are not an only natural applications for such design pattern. Seems like web server or email server also fit this model, and probably many other applications too. So, we need simple and well-defined protocol for communications between Core and Controller. Event queue itself may be as simple as stream of text lines, but Controller must also be able synchronously inquire particular state information from Core and send commands back to Core. wmii use 9p protocols for this, but I feel it as overkill solution. i3 (fork of wmii) and uzbl use it's own protocols based directly on sockets IO. I hope there can be invented some very simple yet extensible meta-protocol that fit needs of most such applications and don't require any IDL. It can be modeled after unix shell with it's plain text command line and optional binary stdin/stdout.

No comments: