If it's because Kate is intending to implement some kind of
collaboratice editing then I'd like to throw in a couple ideas
that I haven't been able to write up and send to this list yet.

Since KDE is such a collaborative environment I thing of this
collaboration framework as functionality on the level KDElibs
like the KIO stuff.  Apps don't think about it, they just it.  To
that end I see this as KDE Infrastructure glue.  The collaborative
messaging architecture is the foundation of KDE as a network OS.

Personally I see collaboration, not as a screen/document sharing
protocol, but more like a MMORPG, where collaborating on a
document is one of the things the users can do.  The distinction
here is that instead of trying to pass mouse/keyboard events
around, we pass game events.  In a realtime game, everyone has
the game engine installed locally (in this case our game engine is
Kate), when the local player does something, it sends an event
to the server saying what it has done.  The server then acts as
a "Message Bus" and redistributes events that the other players
game engine will understand.

Instead of making each localhost the game engine server, I
suggest using XMPP as the "Message Bus" instead.  The
advantage here is that how to pass messages around in a
networked collective and federated environment has already
been well thought out.  It works in both Server and Serverless
environments making architectures very flexible, and the protocol
itself is very extensible making it able to accomodate any need.  
Being based on XML is a good thing as most of us developers
grok XML, and with the latest "Efficient XML Interchange"
standards it looks like it can be light on the network and
processing resources too.

For this to work, I see the localhost desktop hosting an XMPP
server capable of participating in a Serverless Messaging environment
as well as participating in a more formal managed XMPP Server.

Each application can register itself to the local XMPP server as:
userid@localhost/Applications/appname/processid
or something like that.

An editing session could be represented as an XMPP
Multi-User Channel.  Kate applications would be able to join
and leave the session at will.  The session members would use
the channel to distribute the events.  But the beauty of XMPP
is that the members can also publish Presence information about
the state of their App.  For instance, where the cursor is might
be a piece of Presence (or other Custom IQ) information, but
local events that get placed in the undo/redo queue might be
first class messages that go out on the channel.  A new user
joins the session, the get a list of current participants, the session
host sends them the current version of the document, they get the
presence information from all the participants, and they instantly
start getting all the update messages.  Voila, a fully active
participant in a shared document MMORPG.