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
+
Stack 2013-01-07, 21:15
+
Devaraj Das 2012-12-28, 09:31
+
Stack 2012-12-28, 16:59
Copy link to this message
-
Re: Handling protocol versions
On Fri, Dec 28, 2012 at 8:59 AM, Stack <[EMAIL PROTECTED]> wrote:

> On Fri, Dec 28, 2012 at 1:31 AM, Devaraj Das <[EMAIL PROTECTED]> wrote:
>
> > Now thinking more about it, if a server implements a method more
> > efficiently, we probably could have new fields in the method argument to
> > indicate the client is willing to accept the new semantics. A new server
> > could detect that (by checking for existence of such a field), and an old
> > server would simply ignore that field. The new server could do a
> different
> > processing of the request, and the response, although the same message
> > type, might have new fields to capture the response under the new
> > semantics.
> >
> > Over time, the method code might evolve, and might become unmaintainable
> > ... that's the worry. It might make sense to just break up the method
> into
> > multiple implementations..
> >
> >
> Yes.  Protobufs gives us wiggle-room.
>
>
>
> > I am +1 for getting a PB'ed description of the protocol, the client
> caching
> > it, and then deciding which method to invoke based on what's supported in
> > the server. This will also address the orthogonal case of the server
> > letting the client know all its capabilities.
> >
>
>
> This is how a client would learn of completely new functionality that has
> been added to the server?
>
> On client setup of proxy, as first request, instead of asking server for
> the version of the protocol it is serving, instead it could ask the server
> for the pb'd description of the protocol [1] and the client could look at
> this to see if the server supported new functionality?
>
> The returned descriptor would be much fatter than a bitmap.
>
>
Bitmap is fine as well if the PB'ed representation is too verbose.
> St.Ack
>
> 1.
>
> https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/Descriptors.ServiceDescriptor
>