[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-10-03 11:51:59
Message-ID: 20041003120249.GD8797 () lkcl ! net
[Download RAW message or body]

> 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.

okay.

1) the dce idl compiler, like pretty much everything in the dce/rpc
suite, has a plugin architecture.

therefore it is possible to make it understand different input formats,
such that it will generate marshalling/unmarshalling code from, oh, say,
the DCOP file format.

2) an intermediate solution to the serious problem of DCOP not having
type friendliness (did _you_ know that mountwatcher is used in
kdebase/kicker/applets/devices/devicepopupmenu.cpp, because until i did
a grep/xargs through THE ENTIRE kdebase source code, i certainly
didn't!) is to have a second-level IDL compiler which generates structs
containing QStrings to "enhance" all uses of QStringLists.

i DO NOT advocate replacing all uses of QStringLists because that would
be stupid [both stupid in itself and stupid of me to recommend it]

3) extending DCOP's lack of typechecking to other languages - python,
ruby etc. - is NOT a good reason to justify enhancements and a migration
path.

in fact, if anything, it is a good reason _to_ justify getting away from
lack of typechecking as fast as possible.

because you, the kde developers, are _used_ to working with KDE, that's
all fine and dandy: you know your way around the code, and how many
extra bits of stuff have been added, where, when etc., where all the
DCOP interfaces are used.

it's absolute HELL for anyone else who is not.



regarding the "enhancements" to DCOP:

- a small IDL compiler should be written that can take the IDL file and
  generate client-side stub code which "munges" its arguments
  (consisting of structs and lists of structs) into QStringLists that go
  out onto the underlying DCOP interface.

- the client-side stubs should take care of the connection to the DCOP
  interface, such that it is possible to consider linking the
  server-side code with the client-side-usage code, skipping the entire
  DCOP interface altogether, with ZERO code modifications, and for the
  developer to expect it to actually work.

- same deal for server-side.

you've done this once already.


-- 
--
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]