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
