| To: | myllynen@xxxxxxxxxx |
|---|---|
| Subject: | Re: [pcp] fetchgroups api - python bindings |
| From: | Nathan Scott <nathans@xxxxxxxxxx> |
| Date: | Mon, 14 Dec 2015 18:22:27 -0500 (EST) |
| Cc: | pcp@xxxxxxxxxxx |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <566EF368.8000901@xxxxxxxxxx> |
| References: | <20151206204742.GC22561@xxxxxxxxxx> <5666E4F7.4070005@xxxxxxxxxx> <y0m4mft10vf.fsf@xxxxxxxx> <566A59A5.6090403@xxxxxxxxxx> <20151211150348.GH22434@xxxxxxxxxx> <153938084.40304082.1450069736806.JavaMail.zimbra@xxxxxxxxxx> <566EF368.8000901@xxxxxxxxxx> |
| Reply-to: | Nathan Scott <nathans@xxxxxxxxxx> |
| Thread-index: | ipnyCbZHSxXYcMBOD7e1TKkB/symIg== |
| Thread-topic: | fetchgroups api - python bindings |
----- Original Message ----- > > > pmcc is not just a fetchgroup-alike API, it does a number of other very > > useful things too, abstracting code out from high level python scripts. > > what do we actually mean by pmcc? Just pmcc.py or pmcc.py+pmsubsys.py Just pmcc, or a pmcc-like high-level API (provides a fetch loop, metadata caching, options handling assistance, configuration file handling someday and so on). pmsubsys is completely separate (has only one remaining user in-tree, and there's some unfixable assumptions in there esp. relating to interrupts metric handling, for example). pmsubsys is a handy example of how APIs can be very difficult to transition away from. cheers. -- Nathan |
| Previous by Date: | Re: [pcp] Build question (OSX related perhaps), Nathan Scott |
|---|---|
| Next by Date: | Re: [pcp] pmrep: rename -R to -W, Nathan Scott |
| Previous by Thread: | Re: [pcp] fetchgroups api - python bindings, Marko Myllynen |
| Next by Thread: | Re: [pcp] fetchgroups api - python bindings, Mark Goodwin |
| Indexes: | [Date] [Thread] [Top] [All Lists] |