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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: Wednesday, November 19, 2008 7:08 PM > To: [email protected] > Cc: [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > wrote: > > > >>> From: stack <[EMAIL PROTECTED]> > >>> 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 <[EMAIL PROTECTED]> > >>> Subject: Re: JSON support for HBaseRest > >>> To: [email protected] > >>> 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. >
