Re: the evils of the CLD api

On Sat, Jan 16, 2010 at 3:21 PM, Pete Zaitcev <[email protected]> wrote:
> On Sat, 16 Jan 2010 13:38:26 -0800
> Colin McCabe <[email protected]> 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.

>> The event() callback seems like to lead to some complexity. For
>> example, let's say I have a "main" thread that does ncld_open, and
>> then ncld_write. []
>
> Indeed, it reopens the old problems somewhat. The plan is to see
> how ncld matches tabled and chunkd and perhaps tweak the API a bit.
>
>> I guess the main thread could check an atomic variable before each
>> ncldc operation (has_failed? is_gone?) Or a mutex-protected variable.
>
> That's pretty much what I expect from most command-line tools.
> The check is implicit in read/write/lock operations.

The check is built-into the library? That makes sense.

Also, shouldn't the check also be implicit in unlock and close?
Another reason for them to return an error code. :)

>> Rather than the event callback, I almost feel like it would be better
>> just to have an ncldc_poll function modelled on poll(). []
>
> If we do that, we're at the square 1 with respect to complexity
> reduction in a multi-thread environments. If someone wants that,
> they may continue to use cldc_foo.
>
> As a reminder, my aim here is 2-fold:
>
>  1. Provide something that permits to use synchronous programming in
>    cldu.c. I am having a big trouble modifying it, and I know that
>    when we support slave mode, I'll need even more complex behaviour
>    from it. It will crash on itself unless I implement ncld.
>
>  2. Make something that lures new contributors into a sense of simplicity.
>    We keep saying that it's almost like a filesystem, only not quite
>    POSIX. But the actual API is such that nobody will use it if he
>    has an alternative. We need a pseudo-filesystem API to continue
>    making these claims with a straight face.

I think this is a reasonable API. It's nice to see a more familiar
face on read, write, etc. I was just trying to point out another path,
one you might not have thought of.

Colin