[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: RPC Mechanisms (was: Re: [PATCH] bug in latest cvs
From:       Richard Dale <Richard_Dale () tipitina ! demon ! co ! uk>
Date:       2004-09-26 11:33:33
Message-ID: 200409261233.33299.Richard_Dale () tipitina ! demon ! co ! uk
[Download RAW message or body]

On Saturday 25 September 2004 19:09, Guillaume Laurent wrote:
> On Saturday 25 September 2004 19:31, Luke Kenneth Casson Leighton wrote:
> >  if it was possible to transmit a struct:
> >
> >  struct MountPointInfo
> >  {
> >     QString useful_name:
> >   QString mount_point;
> >  QString device;
> >  QString is_mounted;
> >  }
> >
> >  then a) there wouldn't be a problem
>
> Famous last words.
>
> >  a _proper_ RPC runtime environment such as DCE/RPC does all this for
> >  you [...]
> >
> >  and that's one of the reasons why freedce is 250,000 lines of code.
>
> Allow me to chip in with my DCOP user (as in "developper of an app which
> uses DCOP") point of view. The argument I always oppose to people
> criticizing DCOP is that it took me about 20mn to add a DCOP interface to
> the application I was working on, starting with practically zero knowledge
> about it except that, well, it exists. Google, find a quick tutorial which
> says "make a .h with K_DCOP in it, add these lines to your app", do that,
> make, and voila.
>
> DCOP is certainly limited, but its most important feature is that it is
> *SIMPLE*, so simple that using it is considered to be routine work, just
> like adding a widget to a dialog. That's where CORBA utterly failed and why
> it had to be replaced. And though I recall DCE/RPC to be much simpler than
> CORBA, I don't think it's as simple as DCOP. So until it's packaged into
> something at least as easy as DCOP, it will be irrelevant.
>
> Your point about lack of type safety is valid, to the extent that such
> errors would cost significant development time. And general practice seems
> to show that they don't, while using a more complicated RPC mechanism does,
> so it's a very good tradeoff. Think of it as type-strict C++ vs. type-lax
> Ruby. Which one do you think you'll be writing code faster with ? In this
> area, ease of use generally wins over safety features.
While mentioning Ruby, can I add that a big use for DCOP is for scripting 
purposes? If you pass structs where the information could easily be passed as 
a list of strings, then you lose ability to use scripting languages. Passing 
the mount info as struct just because of some anal retentive obsession with 
static typing, to solve 'problems' which don't actually exist, actually 
creates problems for scripting languages where none existed before. 

If someone is going to suddenly rip out the DCOP code, because 'all you need 
to do is reimplement the dcopidl compiler', they haven't considered the 
various interfaces to DCOP in kdebindings that don't use the dcopidl 
compiler. PyKDE, Ruby Korundum, KJSEmbed, dcoppython, dcopperl etc.

I certainly don't mind making changes for D-BUS because it will give use some 
extra useful functionality, but I see no point in messing around with DCOP 
until then, if it's going to break a load of things.

-- Richard
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]