Defining an event loop abstraction

[Avery Pennarun]

On Sat, Nov 19, 2005 at 04:21:25AM +0100, nf2 wrote:

> I already had an interesting discussion on kde-core-devel about the 
> Qt->Glib main loop patch and got some positive feedback, particularly 
> from Trolltech developers (Although they are not very happy with the 
> size of Glib and would prefer to link to a smaller library).
> 
> http://lists.kde.org/?l=kde-core-devel&m=113143586714273&w=2

Note that the proposal in question here is interesting precisely because it
dodges this problem.  If glib provides avahi abstraction (for lack of a
better term), and qt provides an avahi abstraction, and so does libevent,
then you can modify KDE to base all its events on the avahi abstraction
instead of on glib or qt or anything else.  Then, at runtime or link time,
we merely swap out the (very thin) abstraction library with whatever one we
want.

As a bonus, you can actually provide an avahi abtraction even if the
underlying event library didn't feel like providing it for you, which means
you don't have to talk both library vendors into agreeing; the qt guys can
unilaterally choose to make their system work with glib's event system,
and yet not actually require using glib.

Very cool.  Of course, the abstraction has to be "right."  I don't know
enough about GSource and other event systems to know whether the current
avahi abstraction proposal is compatible.

Have fun,

Avery