| To: | Marko Myllynen <myllynen@xxxxxxxxxx> |
|---|---|
| Subject: | Re: Introducing pmrep - Performance Metrics Reporter |
| From: | "Frank Ch. Eigler" <fche@xxxxxxxxxx> |
| Date: | Fri, 30 Oct 2015 12:38:36 -0400 |
| Cc: | pcp@xxxxxxxxxxx |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <563395F1.6040303@xxxxxxxxxx> |
| References: | <560278D5.8010305@xxxxxxxxxx> <5603F9D6.7050306@xxxxxxxxxxx> <159724763.42718898.1443163436257.JavaMail.zimbra@xxxxxxxxxx> <560A9715.4060905@xxxxxxxxxx> <1542966539.49294102.1444091627491.JavaMail.zimbra@xxxxxxxxxx> <563099B1.7000802@xxxxxxxxxx> <980961654.65506823.1446187043033.JavaMail.zimbra@xxxxxxxxxx> <y0mvb9os78v.fsf@xxxxxxxx> <563395F1.6040303@xxxxxxxxxx> |
| User-agent: | Mutt/1.4.2.2i |
Hi, Marko - On Fri, Oct 30, 2015 at 06:08:17PM +0200, Marko Myllynen wrote: > [...] > > The fetchgroup widgets will get a reasonably high-level pmapi.py > > representation. > > to me it almost looks like we already have enough such API user > candidates without pmrep (and actually it might be better to start with > them rather than with pmrep). Quite possibly. > [...] However, pmrep's archive and stdout outputs have some > peculiarities which might then provide a use case on how to use the > generic APIs with custom properties in play (like field width, > decimal count, header printing, etc, all irrelevant for pcp2graphite > and such). The fetchgroup widget would be only for -fetching-. So it is neutral as to formatting or disposal of the resulting values. - FChE |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Introducing pmrep - Performance Metrics Reporter, Marko Myllynen |
|---|---|
| Next by Date: | Re: Introducing pmrep - Performance Metrics Reporter, Marko Myllynen |
| Previous by Thread: | Re: Introducing pmrep - Performance Metrics Reporter, Marko Myllynen |
| Next by Thread: | Re: Introducing pmrep - Performance Metrics Reporter, Marko Myllynen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |