Return-Path: Delivered-To: apmail-hadoop-hbase-dev-archive@minotaur.apache.org Received: (qmail 97299 invoked from network); 1 Jun 2009 20:01:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Jun 2009 20:01:09 -0000 Received: (qmail 78851 invoked by uid 500); 1 Jun 2009 20:01:21 -0000 Delivered-To: apmail-hadoop-hbase-dev-archive@hadoop.apache.org Received: (qmail 78794 invoked by uid 500); 1 Jun 2009 20:01:21 -0000 Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hbase-dev@hadoop.apache.org Delivered-To: mailing list hbase-dev@hadoop.apache.org Received: (qmail 78784 invoked by uid 99); 1 Jun 2009 20:01:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Jun 2009 20:01:21 +0000 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [76.13.9.57] (HELO web65513.mail.ac4.yahoo.com) (76.13.9.57) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 01 Jun 2009 20:01:12 +0000 Received: (qmail 72544 invoked by uid 60001); 1 Jun 2009 20:00:50 -0000 Message-ID: <754427.71237.qm@web65513.mail.ac4.yahoo.com> X-YMail-OSG: asUl3FEVM1n.5cQsrP16YPO2D1gq.tdsq9I1jhW56gO9XgqirpV7Z0HQ4gXJJ0j9t0O_awNFl0uTE3GO_6PbFsZutMhIee8PR1MDcorMvLdibWv7zsXFI4dvE3cJLt8_5.BHFbWeyiRxjtc44LmXfEbIgHz9WIkyV0MdufTR4EEG8AsS7yFBAohyo139vxqwMFEiMfTy3.CWw5409wPx5h5YWx1FwF5XASicXmesVDMlmWgOfFsK4IwK4VgSPxdLGf_3HvHgSfx75xfgQp8mqpAl4XDORLyiluwkbb59Q0zlW073y2v2emUCuyJc9kq8isMLXFBAMIbu2SCN3wwkqxRjmbJEccPMaZP22Q-- Received: from [69.106.5.119] by web65513.mail.ac4.yahoo.com via HTTP; Mon, 01 Jun 2009 13:00:49 PDT X-RocketYMMF: apurtell X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <306154.13329.qm@web65509.mail.ac4.yahoo.com> <7c962aed0906011116h10673da6w744e6a7789ccb908@mail.gmail.com> Date: Mon, 1 Jun 2009 13:00:49 -0700 (PDT) From: Andrew Purtell Subject: Re: contrib proposal: "stargate" To: hbase-dev@hadoop.apache.org In-Reply-To: <7c962aed0906011116h10673da6w744e6a7789ccb908@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1986072271-1243886449=:71237" X-Virus-Checked: Checked by ClamAV on apache.org --0-1986072271-1243886449=:71237 Content-Type: text/plain; charset=us-ascii Answers below inline. ________________________________ From: stack To: hbase-dev@hadoop.apache.org Sent: Monday, June 1, 2009 11:16:52 AM Subject: Re: contrib proposal: "stargate" Sounds good to me. I like idea of REST moving out of core to contrib watched-over by active committer (As you suggest elsewhere, would be good to do for other 'adapters'). Any chance of a basic listing of major API differences from current implementation of REST in TRUNK? [apurtell] The major differences are: - GET, POST, and PUT support more than just just text/xml encoding: Protobufs and binary are also supported - Use GET instead of POST for iterating a scanner instance resource. Personal taste, can be changed. - Supply Cache-Control headers so transparent proxies can do the right thing. - Scanners support batching. - PUT/POST supports batch insert - Different XML schema, but can be easily changed, if it should be - Different resource locators. Avoid using query parameters. OLD: "GET /[table]" returns schema NEW: "GET /[table]/schema" returns schema OLD: "GET /[table]/row/[row](/[timestamp])?" NEW: "GET /[table]/[row]/[column](,[column])+(/[timestamp])?" NEW: "GET /[table]/[startrow](,[endrow])?/[column](,[column]){0,}(/[timestamp])?" - Support suffix globbing of row key NEW: "GET /[table]/[row]*/... <-- suffix glob - Make accidental deletion of table harder. OLD: "DELETE /[table]" NEW: "DELETE /[table]" is disallowed -- prone to accident, like rm -rf / "DELETE /[table]/schema" instead - No need to explicitly enable or disable a table. Capability to do so can be trivially added. Backfill javadoc sounds important, multipart less so. [apurtell] Agree on the javadoc. On AUTH, can you not leverage the container's auth? Should be just configuration to enable BASIC and/or SSL? [apurtell] Yes I believe Jetty can do a lot, and so mostly the enhancements would be about setting up the container properly based on some config, e.g. use SSL listener, but also if we'd consider backing basic auth with data from an HBase table, there would need to be some more involved glue there. Good stuff Andrew, St.Ack --0-1986072271-1243886449=:71237--