One more thing. I'm getting emails about DBus because my name appears in the AUTHORS file, so :
KDE is not switching to DBus
I hardly did anything for DBus
Yes, I do have Qt bindings for DBus pretty much finished. I still have some things that have to be worked on in them but since they're not too high on my todo list right now I can't bring myself to commit that code
Yes, a bridge between DCOP and DBus would be technically possible, but I don't think we will ever go for it. It'd be just another layer
Creating a DBus library that is source compatible with libDCOP would be possible with one assumption - that assumption is that the application/library using libDCOP doesn't access libICE directly. I've never seen anyone doing that so I think we're pretty much safe on that
KDE is not switching to DBus. DCOP is great
I think that's it. Now back to coding and repeat after me : neural networks don't work, nice concept but nothing more, well maybe... but that's not KDE related :)
Syndicate Blogs
Comments
nn
Neural networks do work, but I think we tend to ask them too much :)
DBUS vs DCOP vs god only knows...
while dbus is a neat concept, i think its misplaced. it keeps getting hyped as an event notification system. well the kernel should do that imho, if you cannot do it with basic UNIX IPC. but the biggest thing that will cause me to reject dbus is that it seems to have no clear method to handle types. things like unicode strings can sometimes work with wchar *s and numeric types are okay. but what about a date type? what about a list of something... at this point one would need to introduce a new type system, this i think confuses things and will make it more complex than needed. SysV IPC can handle these types in a trivial manner.
Qt datatypes are at least portably marshallable, but im not about to ask the Gnome camp to use Qt data types. Im sure a dcop <-> dbus bridge could fix this the way we have an xmlrpc bridge, but unless dbus has some compelling reason that i dont know about im not sure its useful it will be.
Well see...
?
I don't see your point. The reason why they want to use DBUS is to have a higher level messaging system that is language-independent, can cross user-boundaries and do things like multicasting events to interested processes. That allows kernel-invoked scipts to tell interested application about new devices, among other things. SysV IPC won't help you with that at all.
Kernel events would only help for events that the kernel knows about and thus solve only a part of the problem. For example when a user plugs in a USB printer a kernel event could be generated. But not when the user plugs in a network printer, the kernel does not know anything about that...
DBUS offers a solution for this problem (more or less, it ignores the security aspect at the moment), the current DCOP implementation does not...
exactly
thats why we should use SysV IPC... if other OS's wish to support the feature then they can use that API...