Accessing remote devices

[David Zeuthen]

Robert Love said:
> On Sat, 2004-01-31 at 19:59, David Zeuthen wrote:
>
>> It seems that what Michael is after, is to standardize how such
>> capability services/libraries should work in a network transparent way,
>> or no?
>
> Hey, David.
>

Hi Robert,

sorry for the late reply - I was travelling all of last week with little
access to email.

> What I think Michael is aiming for is simply for HAL to store the remote
> devices as it does the local ones.
>
> Which is fine and cool, right?
>

Well, I think having HAL daemon instance on both the system hosting
the session and the system hosting the display/sound/input devices is
a better approach.

If we do this, then we simply need to modify libhal to merge
these two device lists at runtime which should be easy. The only
requirement would be to have an environment variable, like DISPLAY,
that the session is setting on login.

(of course, programs connecting through the D-BUS API rather than
libhal would have to respect this environment variable as well)

What about this?

> The question is, how does HAL know about the remote devices.  One
> suggestion Joe and I offered was to have whatever low-level remote
> device discovery daemon the thin client runs simply send out D-BUS
> messages about the new devices.  E.g., very little additional code on
> HAL's part.
>
> HAL could have some sort of 'address' property that would be a remote
> IPC object that the system could use to access the device.
>

Nice idea with the address property - it makes a lot of sense.

Assuming we have separate HAL daemon instances on both the
client and server we can run light processes for IPC on the thin client
that populates said 'address' properties on the local HAL daemon.

> I definitely think that HAL should know about remote devices - I mean,
> that is really neat, right? - but it shouldn't go out of its way.  But
> if there is a way to simply tell HAL stuff like "there is a remote sound
> system at this remote IPC address" then that seems pretty neat, and lets
> HAL continue to be the center of the hardware universe, even on thin
> clients et al. ;-)
>

Heh, basically I think we agree - the only difference is that I want to
run a separate HAL daemon on the client.

I can see issues in the other proposal (having the thin client populate
the device on the HAL daemon on the server) - what happens if the
thin client goes down and stuff?

Thanks,
David