Re: the evils of the CLD api

[Pete Zaitcev <zaitcev@redhat.com>]

On Sat, 16 Jan 2010 17:54:36 -0800
Colin McCabe <cmccabe@alumni.cmu.edu> wrote:
> On Sat, Jan 16, 2010 at 3:21 PM, Pete Zaitcev <zaitcev@redhat.com> wrote:

> >> Shouldn't  ncld_unlock and ncld_close return an error code rather than
> >> just eating all errors? The server certainly does sometimes send back
> >> error responses for these requests.
> >
> > This is an old bone of contention. The problem is, suppose the
> > application is cleaning up for exit. What is it supposed to do with
> > the error code? It cannot even retry sanely.
> 
> If it's important enough for you to print out an error (*not* debug)
> message in the library, it should be important enough to pass along to
> the library user.
> 
> After all, not everyone might be using a command-line app. Some people
> might want to see the error reflected in a dialog box, etc.

I'm going to try and explain again why the tear-down calls must not return
operation errors (they are free to return programmatic errors). This is
an important point for API design.

Suppose for a moment that ncld_end_sess returns an error. What is your
application going to do about it?

You seem to be suggesting to pop a dialog. But what is in the dialog
for the user? What can a user do? The answer is: a) retry, b) resign
to the loss of data and terminate the application forcefuly in the OS.
Or, actually, first (a) and then (b). And for the (b) to work above OS
you'll have a forceful tead-down method anyway (or rely on OS).

What's more, some applications do not have a way to interact with a
human (e.g. tabled). And this is where you got the logics completely
wrong. When I pointed that requirements of such applications dictate
a call that unconditionally ends the life of a structure or handle,
you (correctly) pointed out that interactive applications exist too.
But what of it?! The API must satisfy both kinds!

The correct approach -- and only if you _really_ have no alternative
to have some data outstanding or have other server interaction on
close -- is to provide a separate "flush" method, which can fail.
Then, the retry dialogs or other methods (e.g. copying of data into
other handle) can be used sanely.

-- Pete

P.S. ncld does not have a flush method because its writes are synchronous.
And if we cannot contact a server to close a session, it does not matter.
So the whole discussion is moot really. Nonetheless I think it's important
to have it, in general sense.