Difference between revisions of "DCOP"

From Trinity Desktop Project Wiki
Jump to navigation Jump to search
(Added picture, minor text improvements)
m (Moved categories to bottom and removed empty space)
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Category:KDE3]]
 
[[Category:Architecture]]
 
[[Category:Developers]]
 
{{Applicable to TDE}}
 
 
 
[[File:Servicemenus kdcop.png|thumb|KDCOP is a graphical DCOP browser/client.]]
 
[[File:Servicemenus kdcop.png|thumb|KDCOP is a graphical DCOP browser/client.]]
   
Line 14: Line 9:
 
Two types of actions are possible with DCOP: ''"send and forget"'' messages, which do not block, and ''"calls"'', which block waiting for some data to be returned.
 
Two types of actions are possible with DCOP: ''"send and forget"'' messages, which do not block, and ''"calls"'', which block waiting for some data to be returned.
   
Any data that will be sent is serialized (marshaled, for you CORBA fellows) using the built-in [http://trinitydesktop.org/docs/qt3/ntqdatastream.html QDataStream] operators available in all of the Qt classes. This is fast and easy. In fact it's so little work that you can easily write the marshaling code by hand. In addition, there's a simple IDL-like compiler available (dcopidl and dcopidl2cpp) that generates stubs and skeletons for you. Using the dcopidl compiler has the additional benefit of type safety.
+
Any data that will be sent is serialized (marshaled, for you CORBA fellows) using the built-in [http://trinitydesktop.org/docs/qt3/ntqdatastream.html TQDataStream] operators available in all of the TQt classes. This is fast and easy. In fact it's so little work that you can easily write the marshaling code by hand. In addition, there's a simple IDL-like compiler available (dcopidl and dcopidl2cpp) that generates stubs and skeletons for you. Using the dcopidl compiler has the additional benefit of type safety.
   
 
= External links =
 
= External links =
   
See the following tutorials for further information:
+
See the following resources for further information:
   
  +
== API documentation ==
  +
* [http://trinitydesktop.org/docs/trinity/tdelibs/dcop/html/ Long description of DCOP with examples in the official API documentation]
  +
* [http://trinitydesktop.org/docs/trinity/tdelibs/dcop/html/annotated.html A list of DCOP classes in the official API documentation]
  +
  +
== Tutorials ==
 
* [http://web.archive.org/web/20100126055754/http://developer.kde.org/documentation/tutorials/dot/dcopiface/dcop-interface.html Creating a DCOP Interface]
 
* [http://web.archive.org/web/20100126055754/http://developer.kde.org/documentation/tutorials/dot/dcopiface/dcop-interface.html Creating a DCOP Interface]
<!-- * [http://www-106.ibm.com/developerworks/linux/library/l-dcop/index.html?ca=dgr-kdeml01KDEDCOP Connect KDE applications using DCOP] (dead link, no Wayback)
+
* [http://web.archive.org/web/20070204134744/http://www-128.ibm.com/developerworks/linux/library/l-dcop/index.html?ca=dgr-kdeml01KDEDCOP Connect KDE applications using DCOP] (there are links to even more DCOP tutorials in the bottom of this page)
  +
 
[[Category:KDE3]]
 
[[Category:Architecture]]
 
[[Category:Developers]]

Latest revision as of 15:31, 21 April 2022

KDCOP is a graphical DCOP browser/client.

DCOP is a simple IPC/RPC mechanism built to operate over sockets. Either Unix domain sockets or TCP/IP sockets are supported. DCOP is built on top of the Inter Client Exchange (ICE) protocol, which comes standard as a part of X11R6 and later. It also depends on TQt, but beyond that it does not require any other libraries. Because of this, it is extremely lightweight, enabling it to be linked into all TDE applications with low overhead.

How DCOP works

The model is simple. Each application using DCOP is a client. They communicate to each other through a DCOP server, which functions like a traffic director, dispatching messages/calls to the proper destinations. All clients are peers of each other.

Two types of actions are possible with DCOP: "send and forget" messages, which do not block, and "calls", which block waiting for some data to be returned.

Any data that will be sent is serialized (marshaled, for you CORBA fellows) using the built-in TQDataStream operators available in all of the TQt classes. This is fast and easy. In fact it's so little work that you can easily write the marshaling code by hand. In addition, there's a simple IDL-like compiler available (dcopidl and dcopidl2cpp) that generates stubs and skeletons for you. Using the dcopidl compiler has the additional benefit of type safety.

External links

See the following resources for further information:

API documentation

Tutorials