Tracking whether a connection is alive

[Maciej Katafiasz]

W liście z czw, 15-07-2004, godz. 12:38, Owen Fraser-Green pisze: 
> > I think it's nice as well; the CD burner could export "Burning CD, 4:43
> > remaining" :-)
> >
> > So.. How about making HAL export the name of the connection, e.g. :42-0,
> > as info.locked.dbus_connection and then it's _optional_ to implement the
> > interface org.freedesktop.Hal.LockHolder on the object denoted by the
> > UDI of the device being locked? This interface got two methods
> >
> >  string GetApplicationName(string locale);
> >  string GetReason(string locale);
> >
> > We should of course provide a nice callback for this in libhal.
> >
> > So.. opinions?
> 
> I feel rather uncomfortable with the notion of any application-application
> interface passing natural language text. If you think about the chain of
> actors involved (ignoring some bits in the middle which are just there to
> make stuff work):

Noone's parsing natural language here, see below.

> 1. The user clicking a button
> 2. Client responding to button and trying to get the lock
> 3. HAL
> 4. Application holding the lock
> 
> then this proposal is allowing 4. to pass back something which means
> nothing to anyone except 1. Thus we're asking 4. to make assumptions
> assumptions about something with three degrees of seperation in between.
> IMHO it's a bad thing for anything to assume something about anything
> except it's closest neighbour.

Not really. Those two methods are analogous to standard library call
strerror() for given ERRNO. They serve no other purpose than to give
human-readable description of what's happening at the moment. Similarly,
in case of strerror, you may say there's:
1. User clicking button
2. Client responding to click and trying libfoo call
3. Libc (through ERRNO)
4. Underlying library that performs action resulting in error

But 2, 3, 4 are in fact implementation details, and for user,
description obtained by strerror() is in direct response to his request.

> You already touched on the internationalization issue but what if 4. is a
> root process running on a system set to German locale while the user has
> chosen French locale? What if 2. doesn't communicate to 1. through text at
> all? In fact, the "Burning CD, 4:43 remaining" example isn't even just a
> reason but a operation and a time remaining.

That's exactly why it should be call, and not static property. With
call, app requesting can choose desired locale, with property, that
would be impossible, as well as giving any non-static (ie. some sort of
progress meter) information.

> I do think the goals make a lot of sense though but text should be avoided
> and HAL should stick to providing things which 2. can interpret. The
> application name could be good so 2 can at least tell 1 "I'm sorry but I
> cannot do foo at the moment because bar is currently using the CD-ROM
> burner". In most cases it will be the user who ran 'bar' in the first
> place so this message should make enough sense to them. Other information
> such as "time before lock is freed" could be considered seperately.

Ugh, app can't really "interpret" information. It can fake that in very
limited domain of specific usage, but generally, it can't interpret some
arbitrary information. Just ask Seth how easy it is to parse arbitrary
statement ;). Of course, if we can come up with some set of reasonable,
generic info that apps can make use of, cool. But they just can't
substitute for plain old string describing situation.

> Is there any reason for using a seperate call(s) to get this information
> instead of using putting properties on the devices?

Yes, as given above

Cheers,
Maciej

-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 at wp.pl>
       http://mathrick.blog.pl

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal