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

List:       kde-devel
Subject:    oooo - FreeDCE on the list for evaluation in KDE 4.0
From:       Luke Kenneth Casson Leighton <lkcl () lkcl ! net>
Date:       2005-11-18 17:12:29
Message-ID: 20051118171229.GB25643 () lkcl ! net
[Download RAW message or body]

okay, whose bright idea was _that_ one :)

... actually, it's a really _good_ idea, and a decision on it is
made slightly easier by recent work that removes the dependency
on posix "draft 4" threads emulation layer.

actually, that's a slight lie: the exception handling is still
there and it still uses sigsetjmp and siglongjmp (see later -
it's _not_ as bad as it sounds)

what's changed is that i've renamed every occurrence of
pthread_something to dce_pthread_something, then all occurrences of the
uses of pthread_create() etc. and any other functions which have
slightly different arguments from "draft 4" to "revision 7" i altered
them all to "revision 7" - the posix standard - and then #defined
dce_pthread_something to pthread_something.

so, you _can_ if you want provide your own threading library: it had
just better damn well conform to the posix standard (e.g.
posixthread-win32 which sticks to the damn standard better than
linuxthreads does and that actually causes problems! :)

anyway.

dbus.

don't.

friggin.

use it.

total.

utter.

complete.

waste.

of your time.


dbus does _nothing_ to help you with the actual data marshalling and
unmarshalling.  wow, you got functions to send bytes and strings?  oh,
i'm so haaapppeeee.  where's the friggin IDL compiler??

what do you mean, there's no IDL compiler!!

well if there's no friggin IDL compiler, why have you just WASTED four
years of redhat's money instead of adding a shared-memory-transport or a
unix-domain-socket transport to FreeDCE, which would have taken about
eight WEEKS.

damn.


things you really should know about what FreeDCE does, and what it
doesn't.  FreeDCE is NOT object-orientated.  it is NOT "dcom".  DCOM
_uses_ DCE/RPC.  DCOM is basically an object-orientated "principle"
which is [best] implemented in c++, and is best off using DCE/RPC
as its underlying... thing.  awkward to say, but...

anyway.

the use of FreeDCE inside KDE would be a _staggeringly_ good move.
imagine, just like with Windows NT, being able to _remotely_ run the
"Control Panel" on someone else's computer, back on your machine.

no - i don't mean running X-Windows over an ssh link, i don't mean
running nomachine, i mean splitting out the "control" and "panel" into
a client/server architecture a la DCE/RPC!

that's the sort of thing that you can get, with FreeDCE.

using UDP or TCP not fast enough for you?  write a "local transport" -
ncalrpc, implement it as shared memory _that'll_ be damn fast enough.


anyway.

i promised to mention about dce exceptions.

exceptions are _not_ intended for "every day" - "every
millisecond".  that's why they are called "exceptions".

they do NOT have to be fast.  or pretty.  they have to help you out of a
hole in your code where to jump out of twenty levels of functions and
nested horribleness _without_ exceptions would be like putting a 1000
watt hairdryer on your already-spaghetti'd code.  awful.


anyway [again].  i've done a bit of write-up on MSRPC, FreeDCE, DCOM,
etc. etc. on wikipedia.  take a look at
http://en.wikipedia.org/wiki/User:lkcl and jump from there.

email / cc me with any questions.

and for god's sake don't use D-Bus.

unless you're happy to write your own IDL compiler, in which case
everything is so happy and hunky-dory you'll just love D-Bus.

l.

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