[collectd] memcached:// support in curl plugin

[Doug MacEachern]

Hi Florian,

On Mar 5, 2009, at 11:31 PM, Florian Forster wrote:

> 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..
>

Understood, no problem for me.

>>> 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.
>
Good to know :)

>> 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'.

Indeed, CentOS doesn't have either :(

>> 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])..

ok, so you'd want to require libmemcached then?

>> 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.

ok, sounds good to me.

> 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?

That'd be great!  The patch I just sent for mysql config wasn't too  
difficult, but does seem like it should be easier :)

Thanks,
-Doug

> Regards,
> -octo
>
> [0] <https://bugs.verplant.org/view.php?id=26>
> -- 
> Florian octo Forster
> Hacker in training
> GnuPG: 0x91523C3D
> http://verplant.org/