Tracking whether a connection is alive

[Owen Fraser-Green]

Hi,

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

... which is the source of all too many error messages which make no sense
to most users. The interface between the application and the underlying is
in one domain while the interface between the application and the user is
in another. The underlying library might well convey information to its
caller which make sense in the context of the library call such as "3rd
read retry of sector 0x1532 failed" but the application should usually
just tell the user "Unable to read CD".

Put another way, if your application just had a "Lock CD device" button
maybe the reason text is always going to be appropriate. In most cases,
however, the user begins an action in why domain while the application
makes a series of calls to various things in a lower-level domain and the
reason message is only guaranteed to make sense in that domain.

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

Sorry, my mistake for not reading the parent properly.

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

I agree with the first half of the paragraph - that's why it's OK just to
return the applications name. The plain old string isn't nearly plain
enough though.

Cheers,
Owen


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