glib in kdesupport: yes or no?
mo002j at mail.rochester.edu
Mon Mar 10 20:34:55 GMT 2003
On Mon, 10 Mar 2003, Havoc Pennington wrote:
> One approach is to introduce a D-BUS API that would basically look
> like DCOP but use something like DBusDataStream instead of
> QDataStream. Currently D-BUS only supports a limited set of types, so
> there would only be 9 or 10 overloadings of operator<<.
Yes, but what about the app that sends KMyFancy type over DCOP and
marshalls it to disk both using QDataStream? Especially if much of the
code is shared....
The fact that implementing QDataStream marshalling for some type is
enough to send it over DCOP seems pretty hard to emulate.
And no, this basic scenario isn't all that far-fetched. Konqueror does
that(*) with history.
And of course, having code to marshall in 2 different formats raised my
bloato-meter pressure a lot.
> Another approach is to do an in-process conversion from QDataStream to
> D-BUS format behind the scenes.
I don't see how it's possible, since QDataStream marshalling isn't tagged.
I mean, OK, you could reverse-engineer some cases based on the prototype,
but it's already getting pretty sick.
> If most code is using an "IDL" approach instead of QDataStream
> directly, then it's a good bit easier to keep things looking the same.
Interfaces/Server side is done mostly with an IDL approach.
Callers either marshall directly, or use the DCOPRef template to handle
marshalling and decoration of the argument list.
> Of course it's also possible to make the APIs just be different,
> and not worry about syncing them up.
> Another thing you could do is have special D-BUS messages that
> encapsulate a DCOP message (basically replacing ICE with D-BUS).
2 separate APIs aren't great for developers.
Encapsulation works, but I kind of get a "what's the point?"
Actually, the biggest issue is the security expecations.
DCOP largely has the implicit expecation that only the user can access it.
Add in fancier security model/wider access and some stuff may suddenly
*Well, sort of, since it uses a "compatibility" format over the wire,
while prefers writing a slightly different one to the disk. It was very
accurate of Konqueror <= 3.1.x, though.
More information about the kde-core-devel