nathans wrote:
> [...]
> The volume-skipping analogy is a good one I think. However, some new
> kinds of problems arrive - such as having to deal with differences in
> the metadata between archives, which cannot happen between volumes (as
> they share a .meta file - e.g., metric pmDesc structures might change
> in the new world order, name<->PMID mappings, hostnames - these things
> do not happen in the multi-volume-archive case).
Indeed. Part of this work would be to hide that effect by making
those name/pmid/indom mappings stable across multiple archives.
> You'll also want to think about the data structures you use to represent
> all the archives, and the timespans they cover. [...]
"All problems in computer science can be solved by another level of
indirection ..."
>> >> Streaming live data:
>> >> [...]
>
> I didn't follow the need to talk to pmlogger - what was the rationale
> there?
In the grand unified world, there will be a need to talk to
-something- that has both historical data and live data. Making
pmlogger into a network server would make it possible to have libpcp
engage in conversation with only a single thing. pmlogger already
knows about its own archives as well as the pmcd it's pulling from.
No coincidences or client-side magic required, so to speak.
> Why not treat all archives as potentially live? [...]
In previous context of multi-archive virtual-gluing, it could make the
cross-archive indexing structures uncomfortably dynamic.
> Also, be aware that __pmContext, __pmArchCtl, __pmLogCtl and friends
> are part of the ABI, so we need to be sensitive to any changes in
> these data structures (extending at the end only, etc).
One way around the leakage of these structs into the ABI is to create
new structures and a new shadow-API, all under a separate
symbol-versioning epoch. (Or one can bump the SONAME, and condemn
prior ABI-user binaries to a compat-pcp-libs package from a museum.)
- FChE
|