Yo,
----- Original Message -----
> Hi, Nathan -
>
>
> > [...]
> > > My recent message assumed approximately the same desiderata, and
> >
> > Hmmm - not really convinced of that. In terms of functionality, to
> > me it feels that the latter is a subset of the former. And quite a
> > significant subset in ways that I value (multi-archives, no daemons
> > for archives, and the direct talk-to-pmcd live mode).
>
> Actually, I mentioned explicitly the multi-archives support via the
> new server. "no daemons for archives" was to be different only for
> the multiple-archives case, and it's not a "functionality" subset but
> perhaps a logistical simplification. "direct talk-to-pmcd" was to be
> done via the same new server process,
^^^^^^^^^^^
(so, not direct to pmcd? probably we've got a terminology mismatch &
are talking past each other here. Hmm - just realised that not being
able to talk in the way I consider directly-client-to-pmcd is an even
bigger problem than I'd thought before - see below [*])
> possibly using an
> dynamically-reconfigured archive there as an intermediary. And this
> enables functionality that your scheme doesn't:
Minor point, but lets not talk about "yours" or "mine", please; there's
multiple problems, and multiple potential solution vectors. I like to
think more in terms of a big multi-dimensional search space from which
we get to seek out an optimal solution, given tons of constraints, and
lots of suggestions in the many dimensions.
> automatically
> archiving data that any live-mode client asks for, so that transitions
> between the long-past, the just-past, and live-mode are seamless.
Here, you're saying "enables xxx, and thats good", whereas I'm saying
"mandates xxx, and thats bad" - I'm unconvinced that all tools that want
the usability features we're talking about here should *have* to record
the data first. We're fundamentally disagreeing on that aspect I think,
and I'm certain the some-PMAPI-tool -> tell-pmlogger-what-to-log-when ->
await-the-results-on-disk -> fetch-them-from-disk model is going to be
more complex than the transition-from-log-direct-to-pmcd-fetch model).
[*] Hmmm, thinking out loud - it just won't work at all, will it? - how
does the client tool expand the available (live, now) namespace without
talking to pmcd to know what to tell pmlogger to log in the first place?
> > Last, but not least wrt usability (for some folks anyway - it doesn't
> > bother me after all this time) - we can move away from -h to -u with
> > this new context type, in a controlled, backward-compatible way, over
> > time.
>
> With my proposed scheme, current (-h live-mode) clients would work
> identically: no user interface, nor API use changes, just a different
> -h parameter (to talk to the live-archive server rather than pmcd).
To explain why I don't think this is correct (the backward-compatible
assertions, in particular, trouble me - technically, the API might well
allow the same old bits to be passed, but the *semantics* will become
*so* different when using the new mode, that newer tools will have no
sane pathway with old libpcp ... ugh, that's explained badly sorry) -
I think it'd be worthwhile going through what the pmval code does now
in live host context.
Its a relatively simple tool, but I think it has just enough complexity
to start showing where I think cracks will first appear. Ignoring all
the libpcp magic that we'll need to make happen with whatever scheme we
use, can you describe the changes that will be needed there to make host
mode go back in time and then move forward to seamless live fetching?
I literally do not think its possible with just a pmSetMode() addition,
with current pmFetch semantics for live mode, and the way the current
tools use it - see the call to __pmtimevalSleep(delta) in particular.
And pmchart/pmie/etc are so much more complex than pmval (select loops,
event loops, and so on - we can't sleep(3) in libpcp) - all the tools
will have to change in non-trivial ways to support this. Thus, I think
it makes more sense to introduce that new type of context and to define
new semantics for any/all PMAPI routines that need new semantics, and
update the tools one by one to use 'em.
cheers.
--
Nathan
|