pcp
[Top] [All Lists]

Re: pcp updates - pmdapapi update

To: Lukas Berk <lberk@xxxxxxxxxx>, "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Subject: Re: pcp updates - pmdapapi update
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Mon, 17 Nov 2014 19:41:44 -0500 (EST)
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <20141117230328.GB5700@xxxxxxxxxx>
References: <87oascow3f.fsf@xxxxxxxxxx> <50063157.14443613.1415955185726.JavaMail.zimbra@xxxxxxxxxx> <y0mppclczva.fsf@xxxxxxxx> <237142894.496530.1416263449269.JavaMail.zimbra@xxxxxxxxxx> <20141117230328.GB5700@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: wJHJrBlWLwz+gVzNfm52ZyLoIJ38NA==
Thread-topic: pcp updates - pmdapapi update

----- Original Message -----
> > There's two parts to this problem.  The first part is that patch (for
> > auto-enabling), the second part is during disabling - where do those
> > errors go?  [...]
> 
> Yeah, that part is tricky (and really not much better in the pmstore
> .disable case);

Hmm, not really - life is *much* simpler with pmStore.  It is the
nature of the async operation being introduced here that it removes
opportunities designed into the protocol to report errors.  Whereas
for pmStore, that's not the case - clients are informed of an error
immediately and can report it straight away.

And of course there's no timeouts to shoot the clients in the foot
without them knowing about it.  But that's going over old ground;
we knew these problems existed - there's always trade-offs to be
made & experimentation to be done.

> [...] there are just too many possible failure points.  The

Well, its not really about how *many* failure points there are...

> [...]
> future, perhaps we can explore further our earlier ideas about
> nested/detailed error messages.

...nor is it a nesting/detail problem.  Its more of an asynchronous,
after-the-fact, noone-is-around-to-hear-the-screams-anymore kind of
problem.

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>