Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: JSON support for HBaseRest
Date: Thu, 20 Nov 2008 10:00:39 -0500
Message-ID: 
 <A9052DE662DF3C478FA77DE3773015200250728C@enbossrv03.EnerNOC.local>
In-Reply-To: <4924AA73.6060702@duboce.net>
Thread-Topic: JSON support for HBaseRest
Thread-Index: AclKpD6/2Fh/dmMmSamNLl5DkmqRcAAezndA
References: <49247FD2.7070300@duboce.net>
	 <528821.99154.qm@web65513.mail.ac4.yahoo.com>
 <d8cb87ee0811191548j652edeclc5e016e5599c1b93@mail.gmail.com>
 <4924AA73.6060702@duboce.net>
From: "Brian Beggs" <bbeggs@enernoc.com>
To: <hbase-dev@hadoop.apache.org>

My initial thoughts on this was to take the current REST implementation
that returns xml and refactor it so other types of content could be
returned.  Separating out the content generation and parsing from the
servlet code.=20=20

I do think that it would be beneficial to allow multiple types of
content to be returned by the implementation.  I also believe that
adding a new content type should be fairly simple to add.  I'm not a fan
of having dual REST implementations as provided by the patch in these
JIRA issues:

    https://issues.apache.org/jira/browse/HBASE-814

    https://issues.apache.org/jira/browse/HBASE-815

What I think I'm going to do at this point is to refactor the current
REST implementation to allow multiple enocoders and parsers to work with
the servlets.

Brian

-----Original Message-----
From: Michael Stack [mailto:stack@duboce.net]=20
Sent: Wednesday, November 19, 2008 7:08 PM
To: hbase-dev@hadoop.apache.org
Cc: apurtell@apache.org
Subject: Re: JSON support for HBaseRest

Tom and Andrew, you are right.  Response should be based off the=20
requested content-type (Actually, this is the way it was orginally=20
written but only XML was every implemented: See
http://tinyurl.com/5podrd).

St.Ack*
*
Tom Nichols wrote:
> I agree that you wouldn't want to replace one completely with the
> other, but allow for multiple content encodings.  We're also
> interested in CSV (at least as a retrieval format).  The current REST
> classes would need to be refactored in order to separate the content
> parsing & generation from the actual request and response handling.  A
> simple switch statement based on the content-type (for request) and
> accept header (for response) should be enough; a delegating chain of
> command type of pattern could be slightly more flexible in terms of
> adding new content encodings, but it would probably be overkill.
>
> On Wed, Nov 19, 2008 at 5:50 PM, Andrew Purtell <apurtell@yahoo.com>
wrote:
>=20=20=20
>>> From: stack <stack@duboce.net>
>>> I'd be on for replacing our current XML-based with JSON
>>> if others were OK with that.
>>>=20=20=20=20=20=20=20
>> I agree that JSON is preferable to XML as the default response
>> encoding, but XML should be supported IMHO. In some environments
>> XML is heavily favored, rightly or wrongly.
>>
>>   - Andy
>>
>>=20=20=20=20=20
>>> From: stack <stack@duboce.net>
>>> Subject: Re: JSON support for HBaseRest
>>> To: hbase-dev@hadoop.apache.org
>>> Date: Wednesday, November 19, 2008, 1:06 PM
>>> Sishen Freecity has been looking after our REST interface of
>>> late.  He'd be the best person to chat with.  From my
>>> POV, for sure we'd be interested.  Someone had begun
>>> work on this a while back but it may have been dropped.
>>> I'd be on for replacing our current XML-based with JSON
>>> if others were OK with that.
>>>
>>> Thanks Brian,
>>> St.Ack
>>>
>>> Brian Beggs wrote:
>>>=20=20=20=20=20=20=20
>>>> I am currently working on adding JSON support to the
>>>>=20=20=20=20=20=20=20=20=20
>>> HBase Rest
>>>=20=20=20=20=20=20=20
>>>> implementation.  I wanted to contact the HBase
>>>>=20=20=20=20=20=20=20=20=20
>>> developer community to
>>>=20=20=20=20=20=20=20
>>>> see if either something like this was already being
>>>>=20=20=20=20=20=20=20=20=20
>>> worked on and if
>>>=20=20=20=20=20=20=20
>>>> this something that the community would be interested
>>>>=20=20=20=20=20=20=20=20=20
>>> in having.
>>>=20=20=20=20=20=20=20
>>>> Thanks,
>>>>
>>>>
>>>> Brian
>>>>
>>>>
>>>> This email and any information disclosed in connection
>>>>=20=20=20=20=20=20=20=20=20
>>> herewith, whether written or oral, is the property of
>>> EnerNOC, Inc. and is intended only for the person or entity
>>> to which it is addressed.  This email may contain
>>> information that is privileged, confidential or otherwise
>>> protected from disclosure.  Distributing or copying any
>>> information contained in this email to anyone other than the
>>> intended recipient is strictly prohibited.
>>>=20=20=20=20=20=20=20
>>>>=20=20=20=20=20=20=20=20=20
>>
>>
>>=20=20=20=20=20


This email and any information disclosed in connection herewith, whether wr=
itten or oral, is the property of EnerNOC, Inc. and is intended only for th=
e person or entity to which it is addressed.  =0D
This email may contain information that is privileged, confidential or othe=
rwise protected from disclosure.  =0D
Distributing or copying any information contained in this email to anyone o=
ther than the intended recipient is strictly prohibited.