Accessing remote devices

[David Zeuthen]

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

Yeah, that was my proposal - extend libhal to talk to multiple HAL
daemons. This would mean light traffic as you are describing above.

How the data, e.g. when retrieving pictures from a camera, is actually
transported is up to the library/service handling capability 'camera' or
whatever. D-BUS is one option.

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

Are you suggesting that the library used for retrieving e.g. pictures
(could be gphoto) run locally on the thin client, or are you suggesting
that it runs on the terminal server?

It seems you are suggesting the former, I think that I've read somewhere
that the SunRay system does the latter by encapsulating USB traffic in
TCP, UDP or something.

I'm not sure what is the best method, there are pros and cons for each -
I think it comes down to whether you want to support really thin clients
or support desktop PC's as clients.

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

HAL does stores the type along the the property, and there is indeed a
GetAllProperties() method to avoid multiple round-trips.

For the full API, see

 http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html#AEN140

Cheers,
David