Same for the Ruby API - let's put it into the Ruby package if we think it's stable enough. -ps
Shanti Subramanyam - PAE wrote: > How about if the PHP client is delivered in the PHP package ? That way, > PHP developers have ready access to it. > > Shanti > > Stephen Hahn wrote: > >> * Roy Lyseng <Roy.Lyseng at sun.com> [2007-09-24 13:41]: >> >>> Hi, >>> >>> I am writing the ARC case for memcached, and I need some guidance on >>> file names, components to include and packages. >>> >>> As a matter of fact, the ARC case is already filed as LSARC/2007/385. >>> >>> 1. Where shall we put the binaries and libraries? I see that some >>> similar tools are put in /usr/bin, some are put in /usr/sfw, and some >>> have their own /usr subdirectories, such as /usr/apache2. >>> >>> What is the recommended practice for this? >>> >> >> /usr/sfw is an obsolete tree; no new packages should deliver content >> there. >> >> If a developer would typically run a private instance of memcached, >> then /usr/bin would be appropriate; otherwise, daemons live in >> /usr/lib. (The SMF service description would be how an authorized >> user activates the service.) >> >> >>> 2. Components. >>> >>> It is obvious that we include the memcached server as a component, but >>> what about the client libraries? My thought on this is that a memcached >>> server without a client library is pretty useless, so I would like to >>> include some of the important clients in the ARC case. >>> >>> The list of clients that I suggest are: >>> >>> Perl API >>> PHP API - PECL >>> Ruby API >>> Java API >>> libmemcache (C API) >>> pgmemcache >>> >>> Not sure about the last one - and it may just as well belong in Postgres. >>> >> At present, no consolidation delivers a Ruby install. I would expect >> the others (although I, too, don't know much about pgmemcache). >> >> >>> 3. Packaging >>> >>> Ideally, each component would go into their designated package, but for >>> simplicity I am thinking about putting the server and all clients into >>> one package. Opinions? >>> >> Deployers might prefer to minimize based on the languages they >> install, which would argue for 4+ packages. Certainly the C API >> should be bundled with the package delivering memcached. >> >> - Stephen >> >> > _______________________________________________ > webstack-discuss mailing list > webstack-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/webstack-discuss > -- Prashant Srinivasan Market Development Engineering Sun Microsystems, Inc. 260 Constitution Drive, UMPK-24-201 Menlo Park, CA 94025, USA Voice: 650.786.0610 Fax: 650.786.9555 Concall: 866.545.5227(Outside USA: 865.673.6950) access 7514857 GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x82FBDE5A
