Tracking whether a connection is alive

[Maciej Katafiasz]

W liście z czw, 15-07-2004, godz. 15:12, Owen Fraser-Green pisze: 
> > 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".

Well, remember that string error message isn't the only error indicator
app gets. Primary interface is ERRNO, and strerror() is just helper
call. App can still reason based on ERRNO's value, and show thing like
(completely made up) "Unable to read file: Disk failure. Error returned
was: 'Block 0x1345 read error'", so that it actually shows everything
you'd like it to, and more :). Also, if you think that info is going to
bother your usersm you can always hide it under "Details", or "More
info" button.

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

Hmm, no, I don't think there is any mismatch. App1 and App2 are both
user-level app, and try to use the same device - so obviously they have
very high chance of operating in matching domains, and incidentally,
it'll also be current user's operation domain ;)

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

Yeah, that was probably oversighted / understated in original post. But
string was never meant as a way of interapp communication (at least I
think so ;), just as a way for app to say "if your user insists, tell
him I'm busy because of $reason" to the other app. Internally, apps will
certainly want to exchange much more meaningful (for them, that is)
data. That should indeed be taken into account in design of this iface.

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