[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:       Luke Kenneth Casson Leighton <lkcl () lkcl ! net>
Date:       2004-09-25 17:31:38
Message-ID: 20040925173138.GE19543 () lkcl ! net
[Download RAW message or body]

On Sat, Sep 25, 2004 at 01:50:13PM +0200, Adriaan de Groot wrote:
> [Presuming you're ranting about hand-coding DCOP calls -- you don't actually 
> give any details about what you find wrong, frustrating, or type-unsafe about 
> DCOP calls.]
> 
> On Saturday 25 September 2004 12:59, Luke Kenneth Casson Leighton wrote:
> > okay, the reason why i am pissed is because you are struggling
> > with lack of assistance from the DCOP design itself: the
> > knowledge about the client-server infrastructure and usage is
> > locked into people's heads rather than codified in an "IDL"
> > format that causes compile-time errors.
> 
> DCOP interfaces are generated from .h files which have the special k_dcop 
> macro in them (or was it K_DCOP?). These can be used to generated both stubs 
> and .. something else. The something else is used in the implementation of 
> the DCOP interface, the stubs can be used to call the interface from 
> elsewhere in a type-safe manner because they generate C++ methods that you 
> can call; the methods themselves handle the gory details of the marshalling 
> of arguments and decoding of the gobbledygook that is inside the messages. 
> This is much preferred to hand-coding a (type-unsafe) DCOP message yourself. 
> Of course, it _does_ mean that you need a single .h file that describes the 
> interface you want to talk to.
 
 ... then why am i seeing code that shows people setting up arrays of
 QStrings rather than passing around structures?

 for example, case in point: if you download the source for
 kdenonbeta/kvm out of latest cvs, compile and run it, it fails
 miserably with KDE 3.3.0 release.

 why?

 because there is no support for structures in DCOP, the function
 "basicDeviceInfo()" returns a list of QStrings, the number and meaning
 of which has changed.

 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 b) you could support different
 versions of the same interface c) at the very worst you'd get a
 compiler error.

 _then_ i found also that the same thing occured with the mount point
 stuff for the "Eject" menu.

 a _proper_ RPC runtime environment such as DCE/RPC does all this for
 you _and_ it can help distinguish between in and out parameters _and_
 whether the objects being pointed to can be NULL or not.
 
 _and_ manages / cleans up memory for you so that your
 expectations of the usage of the client/server interface are as
 if you'd compiled the client code with the server code together, with
 no R as in Remote of RPC.

 and that's one of the reasons why freedce is 250,000 lines of code.

 it should have been more, but The Open Group "had instructions"
 shall we say to rip all of the encryption code and as many
 references to kerberos as they could.

 l.


> 
> 
> -- 
>    KPilot - www.kpilot.org - HotSync Solutions for KDE

-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />

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