[collectd] memcached:// support in curl plugin

[Florian Forster]

Hi Doug,

On Wed, Mar 04, 2009 at 12:17:49AM -0500, Doug MacEachern wrote:
> > Did you talk to the cURL guys already? [...]
> 
> Nope I didn't post to any of the cURL lists,  mainly because it
> looked very much intentional having them all static to url.c.  If you
> want to make the proposal/patch there, that'd be great.

okay, I will. I'm just having very little time right now, so this may
take a few days..

> > I've put your changes into a separate plugin, but unfortunately I
> > couldn't delete as much code as I had hoped, so I'm not 100%
> > satisfied.
> 
> Looks great, thanks!  I feel guilty not having done the work myself,
> but less so since you agree we should be able to shrink it more ;)

Don't worry about it, it wasn't much work.

> Hmm, didn't know about libmemcache, but it seems both authors have
> agreed on libmemcached:
> http://lists.danga.com/pipermail/memcached/2007-December/006111.html

I just searched the Debian Apt repository for `memcached' and
`libmemcache' was the only library I've found there. I only noticed the
missing `d' when wondering why the header file wasn't found by configure
;) Too bad the Debian developer didn't turn to `libmemcached' when
`libmemcache' became abandoned. To date, there is not Debian package for
the new `libmemcached'.

> But yes, it probably would make sense for the existing memcached.c
> plugin to use libmemcached if available and also to support the custom
> payload based stats.

In fact, I would simply remove the partial implementation of the
protocol in the existing. There is no real need to implement the
protocol yet again and incomplete, and we've had problems with it in the
past ([0])..

> So where do we go from here on this?  I'm happy to take your
> direction and work on the implementation.  But have no problem of
> course if you want to run with it, in which case I'll move on to
> another unrelated patch :)

All things considered, I think I like the separate `memcachec' plugin
best, with one big `memcached' plugin with all things to do with
`memcached' (the daemon) in it being second place.

I think the way to go is to take the `utils_tail_match' module and make
it general enough to be used by the `curl', `memcachec' and `tail'
plugins. For that, we first need to move the actual `tail' stuff out
first:

 * Move the call to `cu_tail_read' to the `tail' plugin.
 * Change the signature of `tail_match_read' to:
     int tail_match_read (cu_tail_match_t *obj,
         const char *buffer, size_t buffer_size);

Then move the configuration handling code into that module. For this,
change the signature of `tail_match_add_match_simple' to:

  int tail_match_add_match_simple (cu_tail_match_t *obj,
      oconfig_item_t *ci,
      const char *plugin, const char *plugin_instance);

I hope this would eliminate handling of the <Match> bocks in all three
plugins and ensure the same behavior in the future.

As a long-term goal I'd try to simplify the configuration handling in
general by providing easy to use functions, possibly similar to Apache's
concept..

Any thoughts?

Regards,
-octo

[0] <https://bugs.verplant.org/view.php?id=26>
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090306/8bbd3f3b/attachment.pgp