More on the subject of the internal implementation than the method of communication, I believe a setup as follows for a drawing interface makes sense: Wrappable function: grabDrawingRequests , this would allow for multiple methods of communication and protocols to be implemented in plugins (such as over a shared memory transport, dbus, text file, etc). grabDrawingRequests would be called before the screen is painted. Plugins wrapping grabDrawingRequests would be responsible for translating from their method of communication to a format internal to the compositor (The format inside the compositor could be relatively simple as there are very few things required to set up complex drawings). Another function such as addDrawingRequest(CompDrawingRequest * dr) would likely be added as a utility for plugins to add the resulting internal format drawing request to a linked list. Core would be responsible for doing the actual painting at appropriate points during screen painting. It also seems reasonable to consider the idea of a wrappable handleDrawingRequest function but this seems like it is not desirable. Plugins would be required to identify whether they wanted to handle the request based on some flag in a structure, this would become a mess to handle and in the long run probably be less extensible. I'm out of town until Sunday but should be able to get some code working for this next week. Regards, Robert