--nextPart2426470.JEI3ZNQ1WL
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 29 September 2004 17:40, Ian Reinhart Geiser wrote:
> I guess I have been more on the "lets use dcop" vs "lets develop dcop" end
> of things so I have some perspectives.  For the record I am still not for
> or against either approach yet.  I do have some desires for KDE 4's IPC
> but that is it at this point.
>
> For DBUS:
> a) Someone else will maintain the foundation.
> b) Its maintained (although i hear maksim has a libice impl of his own)
> c) Unified IPC w/ other linux desktops
> d) IPC between users, and with the OS is simplified. (although I'm not
> convinced of security issues yet)
>
> Against DBUS:
> a) More glib (someone please get these guys the Thinking in C++ book)
> b) No-one has really adopted it yet.  I think HAL uses it to a limited
> extent, and maybe gconf is maybe moving to it?  It all looks like someone
> is waiting for someone else to bite.  This didn't turn out so well with
> DCOP or arts.
> c) We have a fairly good knowledge of DCOP, do we want to abandon
> something that works.
>
> For DCOP:
> a) Tons of code and documentation on how it works.
> b) Relatively bug free
> c) Bindings
> d) As far as i know most if not all known security holes have been worked
> out.

Well, it helps that we disabled TCP access. But as you will see in this=20
thread, TCP access is one of the things people actually like to see in.

DBUS better facilitates things like TCP access in the sense that the idea i=
s=20
to have two separate DBUS'es. One for inter-user communication (system) and=
=20
one restricted to a single user only (the DCOP model). Everything you attac=
h=20
to the system DBUS creates security concerns, which is in one way a bad=20
thing, some of these concerns will prove to be actual security problems. An=
d=20
a good thing, because all services attached to the system DBUS are supposed=
=20
to be designed with security in mind, so when you grant TCP access to the=20
system DBUS it should not imply instant shell access.

That's one of the main reasons why TCP in DCOP is disabled, if you get acce=
ss=20
somehow you basically have a login shell. (The other one is lack of=20
encryption, but that would have been easy to add.)

> Against DCOP:
> a) Basicly we are stuck in our own world unless some how everyone decides
> DCOP is a good idea.
> b) IPC between users is sketchy at best.  In theory it should work, but
> its a pain in the ass.

The fact that the dcop command line tool supports making calls to other use=
rs=20
is one big hack, not a supported feature.

> c) Dealing with Qt types in a QDataStream is annoying outside of Qt.
> Doable, but annoying.
> d) Libice is the work of the devil, and is completely unmaintained.

The devil part is true but it is not entirely bad. Also with the new X.org =
it=20
would actually be feasible to get some features in there. One problem is th=
at=20
libice is a standard part that comes along with X servers. (isn't it ironic=
?)=20
That makes it hard for people with old crappy X servers to install a recent=
=20
version from e.g. X.org, by shipping our own copy as part of KDE we can at=
=20
least be sure that everyone has the right version.

> These are broad points as I see them.  Currently I am leaning to the
> approach of a plugable IPC service.  One that can support things like
> Rendevus, XMLRPC, SOAP, and desktop IPC. =20

I think it's important to keep the remote stuff well-separated from the=20
desktop-only stuff. Maybe we should have a third DBUS dedicated to remote=20
services.

> The other thing I want more than=20
> anything else is a lightning fast local single session, single user IPC by
> default.  If dbus can do this( i have not ported my dcop benchmark tests
> to dbus yet so i cannot answer this) great, otherwise I think we might
> wish to look into this more.
>
> DBUS is great for things like "new disk in drive" or "camera plugged in",
> but the largest usecase we have in dcop right now is "is this app
> running?" and other communication between applications on a single
> session.  I still have not seen answered if dbus can fit both of those
> scenarios effectively.  Waldo,Harry,Havoc please point me to some numbers
> if I am horribly off here.

It would be nice to have some comparison data on performance indeed. I don'=
t=20
see any particular reason why DBUS would need to be any slower than DCOP, t=
he=20
main task of both is to move data into and out of a pipe. The connection pa=
rt=20
may show significant differences wrt performance though, depending on the=20
kind of authentication/authorisation that is performed. We definitly need t=
o=20
gather data on that.

Cheers,
Waldo
=2D-=20
bastian@kde.org  |  Wanted: Talented KDE developer  |  bastian@suse.com
  http://www.suse.de/de/company/suse/jobs/suse_pbu/developer_kde.html

--nextPart2426470.JEI3ZNQ1WL
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQBBWvHEN4pvrENfboIRAtqIAJ4/NDhsS/1lvgT3vUzLzavzBVWnFACcDaLp
ZYJO6pVdPfFxScgRJu4Fb+Q=
=1DXQ
-----END PGP SIGNATURE-----

--nextPart2426470.JEI3ZNQ1WL--