Re: contrib proposal: "stargate"

[stack <st...@duboce.net>]

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?

Backfill javadoc sounds important, multipart less so.

On AUTH, can you not leverage the container's auth?  Should be just
configuration to enable BASIC and/or SSL?

Good stuff Andrew,
St.Ack

Re: contrib proposal: "stargate"

[stack <st...@duboce.net>]

On Mon, Jun 1, 2009 at 1:00 PM, Andrew Purtell <ap...@apache.org> wrote:

> [apurtell] The major differences are:
>
>  - GET, POST, and PUT support more than just just text/xml encoding:
> Protobufs and binary are also supported
>
>   ....
>
>  - No need to explicitly enable or disable a table. Capability to do so can
> be trivially added.
>

All differences seem fine to me.  Current REST is backward compatible IIRC
so way forward would be to deprecate current REST in favor of the stargate
contribution removing current REST in 0.21 (presuming stargate goes into
0.20).

St.Ack

Re: contrib proposal: "stargate"

[Andrew Purtell <ap...@apache.org>]

Answers below inline. 




________________________________
From: stack <st...@duboce.net>
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