Although there's no code yet, I aim to describe briefly how Intelligent Objects (and Messagebus Access Reflection (MAS), although that's a topic for another time) will relate to the ClipboardServer.


What are Intelligent Objects, you ask?

They're essentially small components that connect to a parent program (such as the ClipboardServer) in a "magnetic" manner using the system messagebus and a defined API.

In order to keep things portable, and to save effort being duplicated between the clipboard utility, clipboardd daemon and the core ClipboardEngine that the two depend on, a set of Intelligent Objects (called Adaptors in the case of ClipboardServer) are used.

These add functionality such as support for storing an amount of text to be pasted quickly into another process using the middle mouse button, interoperability with/replacement of the traditional X11 clipboard with the unified file-backed one provided by ClipboardServer, support for D-BUS accessibility (through MAS), network transparency, hooks into the clipboard-handling routines of processes running in other Personalities and a file conversion system.

An example of an Adaptor chain in use could be (all notifications are routed via the system Messagebus):
User selects text in CLI application -> Personality Subsystem notifies clipboardd -> clipboardd wakes up ClipboardEngine -> ClipboardEngine probes Messagebus for an Adaptor (textSnarf in this case) -> ClipboardEngine copies text and additional raw data to $HOME/.clipboard/textSnarf_raw.

At this stage, the "snarfed" text can be pasted into another application by pressing the 3rd mouse button (or the middle mouse wheel in most cases), a very similar process happens:
User hits 3rd button -> Personality Subsystem notifies clipboardd of activity -> clipboardd notifies ClipboardEngine -> ClipboardEngine probes for textSnarf -> textSnarf reads it's data file -> textSnarf passes data up to ClipboardEngine -> ClipboardEngine then notifies Personality Subsystem -> Application notified -> Data inserted

I forgot to mention that prior to all of this happening, each component in the chain has a unique Messagebus ID, and polling is done for an activity handler in the background to take care of the user's request, and that the current concept has too many steps currently on the "route home" to give the data back to a process.