Monday, August 13, 2007

One main advantage of using/programming in KDE

IPC is a common problem for system programming. If IPC mechanism is designed poorly, the cost comes when the software needs scalability. However, designing full blown IO framework upfront is painful. ( Blocked forever is the worst case, and I may not want to think of non-blocking or asynchronous by signal yet. ) If this bothers, I recommend using DCOP interface.
Example will explain better. I am reading documents using 'kpdf'. And I want to trace my reading on this document. One application of this log will be my reading speed on this document.
If you are running KDE, dcop server is already running. If not, dcop server can be still manually started. Assuming we have dcop server, try this command.


Then, a list of dcop(pable) application will appear. Then,

$ dcop kpdf-6961 kpdf currentPage

Walla. It gave me current page that I am on. If you play with dcop a little further, you will be amazed that it can be a better way to talk to another process. Registering a function to dcop(pability) isn't hard either. If IPC should be considered for local application, this approach should be very appealing.

No comments: