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

Switch to Plain View
HBase >> mail # dev >> Handling protocol versions


+
Devaraj Das 2012-07-31, 00:47
+
Jimmy Xiang 2012-07-31, 03:09
+
Ted Yu 2012-07-31, 03:11
+
Ted Yu 2012-07-31, 21:50
+
Stack 2012-08-01, 08:41
+
Todd Lipcon 2012-08-01, 18:04
+
Andrew Purtell 2012-08-01, 19:39
+
Devaraj Das 2012-08-03, 18:40
+
Stack 2012-12-27, 20:05
+
Jimmy Xiang 2012-12-27, 21:13
+
Enis Söztutar 2012-12-28, 01:37
+
Stack 2012-12-28, 03:11
+
Stack 2013-01-02, 00:44
+
Elliott Clark 2013-01-02, 22:34
Copy link to this message
-
Re: Handling protocol versions
On Wed, Jan 2, 2013 at 2:34 PM, Elliott Clark <[EMAIL PROTECTED]> wrote:

> Removing the versioning altogether seems good.  That leads to much less
> coupling between the client and the server.
>
> I would vote to use BlockingInterface (to replace our versioned protocol
> class) everywhere and just write our own rpc/ipc.  Stack walked me through
> some of the code that is needed for using all of the Protobuf Service and
> Protobuf Blocking Channels; That route seems to have lots of it's own
> cruft.  So if we're going to have a clean up, we shouldn't start out with
> something knowing the result will be crufty.
>
>
Let me try doing the above (Removing versioning and not going the pb
Service route).  We can't use BlockingInterface to replace
VersionedProtocol... BIs do not have a common ancestor.   Let me play
around....  I'll be back.
> Additionally we should move the exception responses into either the header
> or the body.  As it currently stands having to conditionally cast the next
> message into either a response or an error just seems like we're
> re-implementing protobuf's optional.
>
>
I think this a good idea.  Will try this too.

Thanks E,
St.Ack
+
Devaraj Das 2012-12-28, 09:31
+
Stack 2012-12-28, 16:59
+
Devaraj Das 2012-12-28, 17:22