LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris

[Lloyd L Chambers]

Wouldn't /usr/bin/memcached make more sense then /usr/memcached/bin?

I think a namespace like memc_cat, memc_stat, memc_error would be good.

Lloyd


On Feb 25, 2008, at 1:55 PM, James Gates wrote:

> I'll ask Roy about the Java API & if the probes have been discussed  
> with the community.
>
> As for putting the commands in /usr/memcached/bin, we thought that  
> names like 'memcat', 'memstat', 'memerror', etc. *are* too generic,  
> and were preempting complaints about such commands in /usr/bin.
>
> I think the project team would be happy to locate them in /usr/bin.
>
> Does anyone in LSARC have a view on the issue?
>
>
> Danek Duvall wrote:
>> On Wed, Feb 20, 2008 at 12:10:45PM -0500, James Gates wrote:
>>> 4. Technical Description:
>>>   4.1  Details
>>>        The update to the memcached daemon is mostly a version  
>>> upgrade.
>>>        An additional option is made to enhance large memory  
>>> utilization.
>>>
>>>        The Java API was described in LSARC/2007/385, but was not  
>>> included
>>>        at that time due to missing OSR approval (time constrained).
>> You don't list the Java API in the interface table.  What's the  
>> commitment
>> level?
>>>        The libmemcached C API includes a set of binary utility  
>>> programs.
>>>        These are all placed in the /usr/memcached/bin directory  
>>> and are given
>>>        a Volatile stability classification.
>>>        They are only meant for ad-hoc use.
>>>        Their man pages are placed in /usr/memcached/share/man.
>> Hrm.  I'm really not a big fan of creating new entries under /usr  
>> just for
>> a handful of utilities.  At the very least, the man pages should  
>> just go in
>> /usr/share/man (otherwise they're not discoverable).  Probably the
>> utilities should go in /usr/bin.  The names are somewhat generic,  
>> but not
>> hugely so.
>>>        Dtrace probes are described in attached memcached_dtrace.d.
>> Have you run the probes past the dtrace community?
>> Danek

---
Lloyd L Chambers
lloyd.chambers at sun.com
Sun Microsystems, Inc