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. >> > >> > > > > >
