Hi Lukas,
----- Original Message -----
> [...]
> > There is some deb packaging work needed here - all shared libraries need
> > to be separate packages there, I'll help with that tomorrow. That makes
> > me wonder though - is this likely to expand in scope down the track? - I
> > can imagine lots of other www-related helper code needing a home - should
> > we name it more generically? - libpcp_web? (or something else, betterer).
> > Renaming it later will mean packaging pain, so ... maybe pre-empting that,
> > if you agree this might be needed later?
>
> Ah, good call on the debian packaging, will start looking into it.
OK - its fairly straightforward, use debian/*import1* as a template if you
want to hack on it - else, toss it over the fence to me & I'll get it done.
> Hm, I'm not sure on the libpcp_web name, it depends on how else you're
> envisioning expanding the library. If it can be as simple as using
> (for example), libpcp_http for fetching web metrics, and then using
> libpcp_json to interpret the response, I'm leaning towards keeping this
> library smaller and focused. Definitely open to changing the name if it
> makes sense though! Just unsure of how else you're thinking about
> growing it.
Couple things in the back of my mind - firstly, the small http client code
(libpcp_http) is only built statically, currently, since pmdaapache is the
only user atm (iow no .so there yet - but we plan on more (e.g. pmdadocker)
so now would be a good time to address that instead of adding separate deb
packages and libs for http and json). IOW, we could definitely include it
in a libpcp_web.so instead of a libpcp_http.so. Then there may be a need
for things like a little URL parsing routine, maybe parts of pmwebd could
be made into APIs for other web servers (Apache module?) someday ... those
are the kinds of possibilities that are making me wonder, anyway.
But none of that may ever come to pass - its just a thought bubble. :) So,
either way is fine by me - you did the work, you choose.
cheers.
--
Nathan
|