nathans wrote:
> Personally, I was unconvinced that the recent round of suggestions was a
> step forward, so for me definitely not "replaced" ...
> I do still have a strong preference for Plan A; everything stated
> there matches my current thinking re the ideal long term approach we
> should take ("Plan A" being:
> http://oss.sgi.com/pipermail/pcp/2013-September/003963.html)
That message spells out a number of capability/user-interface
desiderata, without much of a proposal for implementation mechanics.
Since that message, further conversation indicates Nathan believes
that libpcp would be a good place for all the intelligence needed to
overcome the many complex issues he lists.
My recent message assumed approximately the same desiderata, and
proposed a specific two-staged implementation. Here, libpcp does not
carry any significant complexity, only the single-growing-archive case
("stage 1", "-a ARCHIVE"). For the more-complex cases ("stage 2"),
all the intelligence would be loaded into a server process, to whom
pcp clients would connect using a slightly extended pcp wire protocol,
but the same "-h SERVER" user interface.
So we need to resolve which of these should be pursued. However, for
brolley's purposes, initial focus on the single-growing-archive case
seems to be common to both possible paths.
- FChE
|