hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sishen <sishen.freec...@gmail.com>
Subject Re: JSON support for HBaseRest
Date Thu, 20 Nov 2008 17:47:38 GMT
Agree.

Allow multiple types of content is beneficial.

As you said, we need to seperate the encoder part and also the decode part.

On Thu, Nov 20, 2008 at 11:00 PM, Brian Beggs <bbeggs@enernoc.com> wrote:

> 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.
>
> 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]
> 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
> requested content-type (Actually, this is the way it was orginally
> 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:
> >
> >>> From: stack <stack@duboce.net>
> >>> I'd be on for replacing our current XML-based with JSON
> >>> if others were OK with that.
> >>>
> >> 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
> >>
> >>
> >>> 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:
> >>>
> >>>> I am currently working on adding JSON support to the
> >>>>
> >>> HBase Rest
> >>>
> >>>> implementation.  I wanted to contact the HBase
> >>>>
> >>> developer community to
> >>>
> >>>> see if either something like this was already being
> >>>>
> >>> worked on and if
> >>>
> >>>> this something that the community would be interested
> >>>>
> >>> in having.
> >>>
> >>>> Thanks,
> >>>>
> >>>>
> >>>> Brian
> >>>>
> >>>>
> >>>> This email and any information disclosed in connection
> >>>>
> >>> 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.
> >>>
> >>>>
> >>
> >>
> >>
>
>
> This email and any information disclosed in connection 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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message