다른 자리에서도 말씀드렸듯이, 저는 멤캐시드 생태계/커뮤니티의 많은 가치가 잘 정의된 클라이언트 API와 잘 정의된 네트워크 프로토콜에서 비롯된다고 생각합니다. 이 프로토콜은 여러분이 필요로 할 수 있는 많은 종류의 것들에 적합합니다(노스케일의 더스틴 살링스 호출) 엉성한 LRU 분산 해시맵.
제가 생각할 수 있는 모든 플랫폼과 언어에 대한 클라이언트가 있으며, 다른 클라이언트를 위한 프로토콜의 기본을 구현하는 것은 매우 간단하기 때문에 부분 클라이언트가 많이 나와 있습니다. 서버 측에서도 마찬가지입니다. 지난 몇 년 동안 멤캐시드 프로토콜의 전체 또는 일부만 사용하는 것들이 꽤 많이 등장했습니다. 어떤 경우에는 이러한 것들이 전체 프로토콜을 사용하지 않는다는 사실을 매우 명확하게 명시하고 있고, 어떤 경우에는 고려하지 않은 부분이 있을 수도 있습니다. 멤캐시드 프로토콜을 사용하는 무언가가 모든 연산과 옵션을 지원하는지 빠르게 확인할 수 있는 방법이 필요했습니다. 이를 위해 스파이멤캐시드나 라이브러리멤캐시드를 가져와서 테스트를 실행할 수도 있었지만, 이는 스파이멤캐시드와 라이브러리멤캐시드의 기능을 검증하는 테스트처럼 느껴졌기 때문에 프로토콜 지원이 되지 않아서 실패한 원인을 파악하려면 해당 프로토콜에 대해 많이 알아야 했습니다. 저는 이와 비슷한 것을 이슬비 개발자의 날 얼마 전 시애틀에서 만났습니다. 이후 대화에서 브라이언 애커 저는 멤캐시드는 거의 모든 개발자가 몇 시간 또는 며칠 안에 기본 기능을 구현할 수 있다고 제안한 바 있습니다. 그렇기 때문에 프로토콜을 어느 정도 준수하는지 확인할 수 있는 간단한 도구가 있으면 정말 유용할 것 같았습니다. 그는 동의했고, 그 후 그와 트론드, 그리고 트론드와 제가 따로 논의한 끝에 멤캡 가능. Trond가 첫 번째 버전을 구현했습니다. 제가 기여한 것은 아이디어와 Trond와의 논의, 그리고 이름 자체(제가 직접 말하자면 멋진 이름입니다)였습니다. 멤캡 가능은 이제 막 libmemcached의 트렁크 를 유틸리티 중 하나로 추가했습니다. 이는 다음 릴리스에 포함될 예정이라는 뜻입니다. 노스케일 자체 패트릭 갤브레이스 (일명 캡토푸)는 최근 도쿄 타이런트(Tokyo Tyrant)를 선택해 이 기능을 시험해 보았습니다. 멤캐시드 사용자가 멤캐시드 사용자를 도와야 하는 것은 바로 이런 종류의 일입니다. 멤캐시드 프로토콜을 구현하는 새로운 사물이 있을 때, 멤캐퍼블을 가리키면 프로토콜의 어느 부분을 지원하는지 빠르게 알아낼 수 있습니다!
