[Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris]

[Roy Lyseng]

Danek Duvall wrote:
> On Tue, Feb 26, 2008 at 03:11:17PM +0100, Roy Lyseng wrote:
> 
>> Java API: The commitment level for the Java API was classified as 
>> Volatile in LSARC/2007/385. Based on recent discussions, I am open for 
>> reclassifying this as Uncommitted, if this is the ARCs opinion.
> 
> Ah, okay.  If you're comfortable that the interfaces are sufficiently
> stable to be considered Uncommitted, then that's fine, and the ARC would
> generally prefer that building blocks like APIs be Uncommitted or better,
> but committing too strongly to an interface is problematic, too.

Really difficult to say, actually, as this is entirely up to the 
open-source community. However, the difference between Volatile and 
Uncommitted seems rather subtle to me :)
> 
>> Dtrace probes: My apologies for not having discussed this. A separate 
>> mail is being sent to dtrace-discuss at opensolaris.org ASAP.
> 
> Thanks.
> 
>>> 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.
>> I have a concern with the utility names too (I would really see them
>> merged into a single utility with subcommands), but of course it is
>> simpler for us to put everything into /usr/bin...
> 
> Yeah, I was thinking that they'd make for good subcommands, too.  What does
> memcached do in its default installation?  What do Linux distros do with
> these utilities?  I would suggest that you ping the memcached community and
> see if they'd be willing to accept a change modifying these commands to be
> subcommands of a wrapper.  But if they've been around a long time and
> reasonably consistently delivered in /usr/bin as-is, then they might not be
> terribly open to that.
> 
> If they *were* willing to accept such a change, then you could integrate
> them as-is in /usr/bin now (as Volatile or Obsolete), and change them
> later, when you get the changes integrated in mainline memcached.
> 
> I'm not going to push you too hard in that direction, though.

I did discuss a change of names with the author of the libmemcached API, 
but he did not see the point of it. So I would not bet on this to happen.

If this may become a more permanent solution, would you vote for 
/usr/bin/memXXX or /usr/memcached/bin/memXXX?

Roy
> 
> Danek