Accessing remote devices

[Marco Canini]

Hi Michael,

premising that I agree with you that d-bus is designed for low traffic
msgs, I'm not convinced on the fact you want to use corba within it.
Many words have been said around d-bus, but what're real?
Isn't d-bus good as it is to do what it has to do?
Or do you want to make something shared between kde and gnome? Replace
DCOP and ORBit2 with one shared piece of software?
The matter is that i don't see a great push from kde to substitute its
dcop nor from gnome with its orbit2.
So ask, what do we wanna do?
Take care of figuring out what's the real role of d-bus for the future
and don't reinvent the wheel.
This my comment is for all us.

Cheers

On Fri, 2004-01-30 at 16:07, Michael Meeks wrote:
> Hi David,
> 
> On Thu, 2004-01-15 at 18:07, David Zeuthen wrote:
> > >   I am trying to access remote devices (specifically a remote CDROM)
> > > using D-BUS / HAL over the network.
> ...
> > Woow, exciting.
> 
> 	:-)
> 
> > D-BUS is designed to work over the network - check the message-bus-list
> > archives. Whether it currently works, I'm not sure. I think there were
> > some issues with authentication, but I dunno.
> 
> 	So - I want to discuss this with Havoc - but really; having spent some
> time analysing D/BUS there are a number of problems with it for doing
> heavy-duty / rich interface IPC - that it appears not to be designed for
> [ instead being ideal for the sort of low-frequence, async event traffic
> that a user-H/W hot-plug type bus thing needs ].
> 
> 	Even the current rather simple use cases seem to be architecturally
> flakey - eg. the implementation of the remote property browser seems
> rather incredible[1].
> 
> 	Ultimately, my growing conviction is that if we want hard-core,
> point-to-point, standardisable device access: passing structured /
> complex data types, D/BUS cannot be the main data channel. [ of course,
> it makes sense to continue using it for the hotplug / device querying
> etc. stuff that it does at the moment ].
> 
> 	I really see two alternatives for the data transport:
> 
> 	a) cut/paste/re-license or re-write a chunk of ORBit2 into
> 	   D/BUS - simplifying/recursivising the type system, adding an
> 	   IDL compiler, object management, auto/mappings etc.
> or:
> 	b) use CORBA for device access; binning problematic bonobo
> 	   lifecycle issues, and using a client side wrapper / more 
> 	   cunningness to remove re-enterancy concerns.
> 
> 	So - I frankly don't much care; but the Gnome project has to continue
> maintaining our light/fast ORB anyway, so cut/paste in general is not
> good for the whole experience. Of course - if the code changes were
> fairly minimal, we could (perhaps) depend on/re-use some of that from
> inside D/BUS.
> 
> 	OTOH - I would propose that we'd want to write an IDL compiler backend
> however we do it to auto-generate an IPC/transport independant set of
> C/C++ bindings; such that we have the freedom to switch the back-end
> implementation to the next IPC hack at some stage.
> 
> 	Of course; the letters 'cOrBa' juxtaposed have some charged political
> issues - which may militate in favour of something new / incompatible /
> differently-named to be implemented - however it isn't D/BUS in it's
> current state.
> 
> 	This is (incidentally) not some random / ill-informed rant, I'm trying
> to get towards a design whereby we can make Gnome work well with
> thin-clients. This is what Kiran is going to be working on full-time for
> many months when we have a real plan; so ... comments appreciated.
> 
> 	Regards,
> 
> 		Michael.
> 
> [1] - as I understand it, a fetch TYPE_ARRAY_STRING of method names, and
> then a slew of PropertyNameGet[Double/Int/Long] type stuff with typing
> done by strcmps of the name ( perhaps misunderstood ).
> -- 
>  michael@ximian.com  <><, Pseudo Engineer, itinerant idiot
-- 
Marco Canini <marco.canini@fastwebnet.it>