Accessing remote devices

[Michael Meeks]

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 at ximian.com  <><, Pseudo Engineer, itinerant idiot