Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # dev - All ok w/ thrift2 going away in trunk/0.95?


Copy link to this message
-
Re: All ok w/ thrift2 going away in trunk/0.95?
Lars George 2013-05-03, 21:21
Understood, but I hope my clarification helped to rectify that. I was not in any way claiming REST is not current, but merely was commenting on the fact that the thread had drifted off into a general PB or not discussion. I still believe Thrift2 is the way to go forward and will work on it. I have started looking at the JIRAs, but they are not very conclusive:

https://issues.apache.org/jira/issues/?filter=-4&jql=project%20%3D%20HBASE%20AND%20component%20%3D%20Thrift%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20ORDER%20BY%20createdDate%20DESC

I was wondering if someone knows what the known issues are. But I can work through that list and check the Thrift2 API against the client API to see what is amiss.

Lars

On May 3, 2013, at 11:14 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> I didn't take offence, but it's a false equivalency.
>
>
> On Fri, May 3, 2013 at 2:02 PM, Lars George <[EMAIL PROTECTED]> wrote:
>
>> No Andy, I was just saying, if we remove Thrift2 for a PB backed gateway,
>> then we could as well remove them all. REST was just an example. No offence
>> meant.
>>
>> Lars
>>
>> On May 3, 2013, at 6:04 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
>>
>>> We don't have a proper REST API? Please provide more detail on what you
>>> think is lacking. The status of Thrift2 and REST are the same? The REST
>> API
>>> is not actively maintained?
>>>
>>> On Friday, May 3, 2013, Lars George wrote:
>>>
>>>> Hi Jimmy,
>>>>
>>>> Inline...
>>>>
>>>> On Apr 25, 2013, at 8:18 PM, Jimmy Xiang <[EMAIL PROTECTED]
>> <javascript:;>>
>>>> wrote:
>>>>
>>>>> At first, I am +1 for removing it.  We had a similar discussion before,
>>>> and
>>>>> didn't pull the plug because of Tim's comment:
>>>>>
>>>>>
>>>>
>> http://mail-archives.apache.org/mod_mbox/hbase-dev/201212.mbox/%3CCAE9meBbH7V1PhSbeGtEpbXg1h5drbS+[EMAIL PROTECTED]%3E
>>>>
>>>> I am with Tim here (it was me that pushed Tim to complete this work in
>> the
>>>> first place).
>>>>
>>>>> To me, instead of complete and maintain Thrift2, it will be much better
>>>> to
>>>>> come up a new one since we are on PB now.
>>>>
>>>> That is independent if you ask me. We should have a proper Thrift one,
>>>> same with REST. Or do you want to toss out REST as well since we now
>> have
>>>> PB RPCs?
>>>>
>>>> I am willing to work and maintain Thrift2, I said that before. This
>> thread
>>>> though got derailed in general wishful thinking, so could we please
>> maybe
>>>> vote if we want Thrift and more especially Thrift2. Because we either
>> throw
>>>> out Thrift in total for PB or maintain it for the time being.
>>>>
>>>> Thoughts?
>>>>
>>>> Cheers,
>>>> Lars
>>>>
>>>>>
>>>>> Thanks,
>>>>> Jimmy
>>>>>
>>>>>
>>>>> On Thu, Apr 25, 2013 at 11:10 AM, Andrew Purtell <[EMAIL PROTECTED]
>> <javascript:;>
>>>>> wrote:
>>>>>
>>>>>> I'm glad someone has stepped forward to be an active responsive
>>>> maintainer
>>>>>> of this piece of code. Maintenance is one issue, actual usage is
>>>> another.
>>>>>> Does anyone actually use this? What is the plan for Thrift? Do we
>>>> continue
>>>>>> with both interfaces through one or more subsequent versions?
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 24, 2013 at 10:45 PM, Lars George <[EMAIL PROTECTED]
>> <javascript:;>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> I am -1 to remove, took a long time to get it in there and should
>>>>>>> deprecate Thrift v1 - or else we are in the same mess as mapred and
>>>>>>> mapreduce is. We once replaced the entire client API and now we can't
>>>> do
>>>>>>> this for Thrift?
>>>>>>>
>>>>>>> I am happy to work on v2 and fix or maintain it. It should be the way
>>>>>>> forward methinks.
>>>>>>>
>>>>>>> Lars
>>>>>>>
>>>>>>> On Apr 24, 2013, at 21:53, Stack <[EMAIL PROTECTED] <javascript:;>>
>>>> wrote:
>>>>>>>
>>>>>>>> Thrift2 was supposed to be the future -- an API like the native java
>>>>>> API
>>>>>>> --
>>>>>>>> but it never got the support needed to make it a superset of