[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544724#comment-15544724
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user erikvanoosten commented on the issue:

https://github.com/apache/thrift/pull/1036
  
The specification documents are up at 
https://erikvanoosten.github.io/thrift-missing-specification/.


> Specify BinaryProtocol and CompactProtocol
> --
>
> Key: THRIFT-3867
> URL: https://issues.apache.org/jira/browse/THRIFT-3867
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation
>Reporter: Erik van Oosten
>Assignee: Erik van Oosten
> Fix For: 0.10.0
>
>
> It would be nice when the protocol(s) would be specified somewhere. This 
> should improve communication between developers, but also opens the way for 
> alternative implementations so that Thrift can thrive even better.
> I have a fairly complete description of the BinaryProtocol and 
> CompactProtocol which I will submit as a patch for further review and 
> discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509144#comment-15509144
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user erikvanoosten commented on the issue:

https://github.com/apache/thrift/pull/1036
  
The feedback cycle took more then a month. This is too long for me. I do 
not have the mental capacity to keep work in my head for that long.

Kind regards,
 Erik.



Op 20-09-16 om 21:49 schreef Jens Geyer:
>
> Why?
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub 
> , 
> or mute the thread 
> 
.
>




> Specify BinaryProtocol and CompactProtocol
> --
>
> Key: THRIFT-3867
> URL: https://issues.apache.org/jira/browse/THRIFT-3867
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation
>Reporter: Erik van Oosten
>
> It would be nice when the protocol(s) would be specified somewhere. This 
> should improve communication between developers, but also opens the way for 
> alternative implementations so that Thrift can thrive even better.
> I have a fairly complete description of the BinaryProtocol and 
> CompactProtocol which I will submit as a patch for further review and 
> discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507642#comment-15507642
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user Jens-G commented on the issue:

https://github.com/apache/thrift/pull/1036
  
Thanks for the reminder. Actually, I like it. Too bad it's closed now.


> Specify BinaryProtocol and CompactProtocol
> --
>
> Key: THRIFT-3867
> URL: https://issues.apache.org/jira/browse/THRIFT-3867
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation
>Reporter: Erik van Oosten
>
> It would be nice when the protocol(s) would be specified somewhere. This 
> should improve communication between developers, but also opens the way for 
> alternative implementations so that Thrift can thrive even better.
> I have a fairly complete description of the BinaryProtocol and 
> CompactProtocol which I will submit as a patch for further review and 
> discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507602#comment-15507602
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user Jens-G commented on the issue:

https://github.com/apache/thrift/pull/1036
  
Why?


> Specify BinaryProtocol and CompactProtocol
> --
>
> Key: THRIFT-3867
> URL: https://issues.apache.org/jira/browse/THRIFT-3867
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation
>Reporter: Erik van Oosten
>
> It would be nice when the protocol(s) would be specified somewhere. This 
> should improve communication between developers, but also opens the way for 
> alternative implementations so that Thrift can thrive even better.
> I have a fairly complete description of the BinaryProtocol and 
> CompactProtocol which I will submit as a patch for further review and 
> discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15424854#comment-15424854
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user erikvanoosten commented on the issue:

https://github.com/apache/thrift/pull/1036
  
All, @Jens-G, this documentation is ready for another review. Thanks!


> Specify BinaryProtocol and CompactProtocol
> --
>
> Key: THRIFT-3867
> URL: https://issues.apache.org/jira/browse/THRIFT-3867
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation
>Reporter: Erik van Oosten
>
> It would be nice when the protocol(s) would be specified somewhere. This 
> should improve communication between developers, but also opens the way for 
> alternative implementations so that Thrift can thrive even better.
> I have a fairly complete description of the BinaryProtocol and 
> CompactProtocol which I will submit as a patch for further review and 
> discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15424308#comment-15424308
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user erikvanoosten commented on the issue:

https://github.com/apache/thrift/pull/1036
  
Note: last commit is still work in progress.


> Specify BinaryProtocol and CompactProtocol
> --
>
> Key: THRIFT-3867
> URL: https://issues.apache.org/jira/browse/THRIFT-3867
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation
>Reporter: Erik van Oosten
>
> It would be nice when the protocol(s) would be specified somewhere. This 
> should improve communication between developers, but also opens the way for 
> alternative implementations so that Thrift can thrive even better.
> I have a fairly complete description of the BinaryProtocol and 
> CompactProtocol which I will submit as a patch for further review and 
> discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15424295#comment-15424295
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user erikvanoosten commented on the issue:

https://github.com/apache/thrift/pull/1036
  
@Jens-G wrote:
> The Thrift compiler prevents the combination of oneway plus throws right 
from the start since March 2003, any types other than void are disallowed since 
THRIFT-2030. So that does not hold.

I looked at it again. `ProcessFunction` in thrift 0.9.3 contains the 
following:

```
try {
  result = getResult(iface, args);
} catch(TException tex) {
  LOGGER.error("Internal error processing " + getMethodName(), tex);
  TApplicationException x = new 
TApplicationException(TApplicationException.INTERNAL_ERROR, 
"Internal error processing " + getMethodName());
  oprot.writeMessageBegin(new TMessage(getMethodName(), 
TMessageType.EXCEPTION, seqid));
  x.write(oprot);
  oprot.writeMessageEnd();
  oprot.getTransport().flush();
  return;
}
```

As you can see when `getResult` throws it is encoded regardless of oneway. 
You may ask when does `getResult` throw? Looking at the generated code, for 
example:

```
  public getById_result getResult(I iface, getById_args args) throws 
org.apache.thrift.TException {
getById_result result = new getById_result();
try {
  result.success = iface.getById(args.userId);
} catch (UserNotFoundException exc1) {
  result.exc1 = exc1;
}
return result;
  }
```

it throws when it can not decode the request, or when the service 
implementation throws any unchecked exception.


> Specify BinaryProtocol and CompactProtocol
> --
>
> Key: THRIFT-3867
> URL: https://issues.apache.org/jira/browse/THRIFT-3867
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation
>Reporter: Erik van Oosten
>
> It would be nice when the protocol(s) would be specified somewhere. This 
> should improve communication between developers, but also opens the way for 
> alternative implementations so that Thrift can thrive even better.
> I have a fairly complete description of the BinaryProtocol and 
> CompactProtocol which I will submit as a patch for further review and 
> discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363053#comment-15363053
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user erikvanoosten commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1036#discussion_r69621679
  
--- Diff: doc/specs/thrift-binary-protocol-encoding.md ---
@@ -0,0 +1,467 @@
+Thrift Protocol Encoding for BinaryProtocol and CompactProtocol
+
+
+Last Modified: 2016-Jun-29
+
+! WARNING !
+
+This document is _work in progress_ and should not (yet) be seen as an 
authoritative source of information.
+
+This text is submitted to the Thrift community for review and improvements.
+
+
+
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+
+
+
+There are many ways to encode Thrift on the wire. This documents focuses 
on the wire encoding for services calls
+(encoding and semantics) in the Thrift older *binary protocol* (which has 
not been documented before) and the
+*compact protocol*. Both the regular socket transport (unframed) and the 
framed transport are described.
+
+Note that no effort is made to group descriptions of behavior of the 
Thrift server and the encodings used in the
+Thrift wire format. The order in which things are described is such that 
you can read the document from top to bottom.
+
+The information here is mostly based on the Java implementation in the 
Apache thrift library (version 0.9.1) and
+[THRIFT-110 A more compact 
format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation 
however,
+should behave the same.
+
+## Message exchange
+
+Both the binary protocol and the compact protocol assume a transport layer 
that exposes a bi-directional byte stream,
+for example a TCP socket. Both use the following message exchange:
+
+1. Client sends a `TMessage` (type `Call`). The TMessage contains some 
metadata and the name of the method to invoke.
+2. Client sends method arguments (a struct defined by the generate code).
+3. Server sends a `TMessage` (type `Response` or `Exception`) to start the 
response.
+4. Server sends completes response with a struct (a predefined struct or 
one defined by generated code).
+
+The pattern is a simple half duplex protocol where the parties alternate 
in sending a `TMessage` followed by a struct.
+What these are is described below.
+
+Although the standard Apache Thrift Java clients do not support pipelining 
(sending multiple requests without waiting
+for an response), the standard Apache Thrift Java servers do support it.
+
+## TMessage
+
+A *TMessage* contains the following information:
+
+* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and 
`Oneway`.
+* _Sequence id_, an int32 integer.
+* _Name_, a string (can be empty).
+
+The *sequence id* is a simple message id assigned by the client. The 
server will use the same sequence id in the
+TMessage of the response. The client uses this number to detect out of 
order responses. Each client has a int32 field
+which is increased for each message. The sequence id simply wraps around 
when it overflows.
+
+The *name* indicates the service method name to invoke. The server uses 
the same name in the TMessage of the response.
+
+When the *multiplexed protocol* is used, the name contains the service 
name, a colon `:` and the method name. The
+multiplexed protocol is not compatible with other protocols.
+
+The *message type* indicates what kind of message is sent.
+
+Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in 
the protocol exchange). Servers send
+responses with TMessages of type `Exception` or `Reply`.
+
+### Oneway
+

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363047#comment-15363047
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user erikvanoosten commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1036#discussion_r69621170
  
--- Diff: doc/specs/thrift-binary-protocol-encoding.md ---
@@ -0,0 +1,467 @@
+Thrift Protocol Encoding for BinaryProtocol and CompactProtocol
+
+
+Last Modified: 2016-Jun-29
+
+! WARNING !
+
+This document is _work in progress_ and should not (yet) be seen as an 
authoritative source of information.
+
+This text is submitted to the Thrift community for review and improvements.
+
+
+
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+
+
+
+There are many ways to encode Thrift on the wire. This documents focuses 
on the wire encoding for services calls
+(encoding and semantics) in the Thrift older *binary protocol* (which has 
not been documented before) and the
+*compact protocol*. Both the regular socket transport (unframed) and the 
framed transport are described.
+
+Note that no effort is made to group descriptions of behavior of the 
Thrift server and the encodings used in the
+Thrift wire format. The order in which things are described is such that 
you can read the document from top to bottom.
+
+The information here is mostly based on the Java implementation in the 
Apache thrift library (version 0.9.1) and
+[THRIFT-110 A more compact 
format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation 
however,
+should behave the same.
+
+## Message exchange
+
+Both the binary protocol and the compact protocol assume a transport layer 
that exposes a bi-directional byte stream,
+for example a TCP socket. Both use the following message exchange:
+
+1. Client sends a `TMessage` (type `Call`). The TMessage contains some 
metadata and the name of the method to invoke.
+2. Client sends method arguments (a struct defined by the generate code).
+3. Server sends a `TMessage` (type `Response` or `Exception`) to start the 
response.
+4. Server sends completes response with a struct (a predefined struct or 
one defined by generated code).
+
+The pattern is a simple half duplex protocol where the parties alternate 
in sending a `TMessage` followed by a struct.
+What these are is described below.
+
+Although the standard Apache Thrift Java clients do not support pipelining 
(sending multiple requests without waiting
+for an response), the standard Apache Thrift Java servers do support it.
+
+## TMessage
+
+A *TMessage* contains the following information:
+
+* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and 
`Oneway`.
+* _Sequence id_, an int32 integer.
+* _Name_, a string (can be empty).
+
+The *sequence id* is a simple message id assigned by the client. The 
server will use the same sequence id in the
+TMessage of the response. The client uses this number to detect out of 
order responses. Each client has a int32 field
+which is increased for each message. The sequence id simply wraps around 
when it overflows.
+
+The *name* indicates the service method name to invoke. The server uses 
the same name in the TMessage of the response.
+
+When the *multiplexed protocol* is used, the name contains the service 
name, a colon `:` and the method name. The
+multiplexed protocol is not compatible with other protocols.
+
+The *message type* indicates what kind of message is sent.
+
+Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in 
the protocol exchange). Servers send
+responses with TMessages of type `Exception` or `Reply`.
+
+### Oneway
+

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363041#comment-15363041
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user erikvanoosten commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1036#discussion_r69620426
  
--- Diff: doc/specs/thrift-binary-protocol-encoding.md ---
@@ -0,0 +1,467 @@
+Thrift Protocol Encoding for BinaryProtocol and CompactProtocol
+
+
+Last Modified: 2016-Jun-29
+
+! WARNING !
+
+This document is _work in progress_ and should not (yet) be seen as an 
authoritative source of information.
+
+This text is submitted to the Thrift community for review and improvements.
+
+
+
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+
+
+
+There are many ways to encode Thrift on the wire. This documents focuses 
on the wire encoding for services calls
+(encoding and semantics) in the Thrift older *binary protocol* (which has 
not been documented before) and the
+*compact protocol*. Both the regular socket transport (unframed) and the 
framed transport are described.
+
+Note that no effort is made to group descriptions of behavior of the 
Thrift server and the encodings used in the
+Thrift wire format. The order in which things are described is such that 
you can read the document from top to bottom.
+
+The information here is mostly based on the Java implementation in the 
Apache thrift library (version 0.9.1) and
+[THRIFT-110 A more compact 
format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation 
however,
+should behave the same.
+
+## Message exchange
+
+Both the binary protocol and the compact protocol assume a transport layer 
that exposes a bi-directional byte stream,
+for example a TCP socket. Both use the following message exchange:
+
+1. Client sends a `TMessage` (type `Call`). The TMessage contains some 
metadata and the name of the method to invoke.
+2. Client sends method arguments (a struct defined by the generate code).
+3. Server sends a `TMessage` (type `Response` or `Exception`) to start the 
response.
+4. Server sends completes response with a struct (a predefined struct or 
one defined by generated code).
+
+The pattern is a simple half duplex protocol where the parties alternate 
in sending a `TMessage` followed by a struct.
+What these are is described below.
+
+Although the standard Apache Thrift Java clients do not support pipelining 
(sending multiple requests without waiting
+for an response), the standard Apache Thrift Java servers do support it.
+
+## TMessage
+
+A *TMessage* contains the following information:
+
+* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and 
`Oneway`.
+* _Sequence id_, an int32 integer.
+* _Name_, a string (can be empty).
+
+The *sequence id* is a simple message id assigned by the client. The 
server will use the same sequence id in the
+TMessage of the response. The client uses this number to detect out of 
order responses. Each client has a int32 field
+which is increased for each message. The sequence id simply wraps around 
when it overflows.
+
+The *name* indicates the service method name to invoke. The server uses 
the same name in the TMessage of the response.
+
+When the *multiplexed protocol* is used, the name contains the service 
name, a colon `:` and the method name. The
+multiplexed protocol is not compatible with other protocols.
+
+The *message type* indicates what kind of message is sent.
+
+Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in 
the protocol exchange). Servers send
+responses with TMessages of type `Exception` or `Reply`.
+
+### Oneway
+

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358600#comment-15358600
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user erikvanoosten commented on the issue:

https://github.com/apache/thrift/pull/1036
  
Thanks @Jens-G . That's all useful feedback. Next week I have time to work 
on it further.

Regarding structure: it took me weeks to collect all this information and 
create the document. At some points I no longer could keep the entire thing in 
my head. Your structure proposal makes sense and clears it for me also :)


> Specify BinaryProtocol and CompactProtocol
> --
>
> Key: THRIFT-3867
> URL: https://issues.apache.org/jira/browse/THRIFT-3867
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation
>Reporter: Erik van Oosten
>
> It would be nice when the protocol(s) would be specified somewhere. This 
> should improve communication between developers, but also opens the way for 
> alternative implementations so that Thrift can thrive even better.
> I have a fairly complete description of the BinaryProtocol and 
> CompactProtocol which I will submit as a patch for further review and 
> discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358089#comment-15358089
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user Jens-G commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1036#discussion_r69231154
  
--- Diff: doc/specs/thrift-binary-protocol-encoding.md ---
@@ -0,0 +1,467 @@
+Thrift Protocol Encoding for BinaryProtocol and CompactProtocol
+
+
+Last Modified: 2016-Jun-29
+
+! WARNING !
+
+This document is _work in progress_ and should not (yet) be seen as an 
authoritative source of information.
+
+This text is submitted to the Thrift community for review and improvements.
+
+
+
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+
+
+
+There are many ways to encode Thrift on the wire. This documents focuses 
on the wire encoding for services calls
+(encoding and semantics) in the Thrift older *binary protocol* (which has 
not been documented before) and the
+*compact protocol*. Both the regular socket transport (unframed) and the 
framed transport are described.
+
+Note that no effort is made to group descriptions of behavior of the 
Thrift server and the encodings used in the
+Thrift wire format. The order in which things are described is such that 
you can read the document from top to bottom.
+
+The information here is mostly based on the Java implementation in the 
Apache thrift library (version 0.9.1) and
+[THRIFT-110 A more compact 
format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation 
however,
+should behave the same.
+
+## Message exchange
+
+Both the binary protocol and the compact protocol assume a transport layer 
that exposes a bi-directional byte stream,
+for example a TCP socket. Both use the following message exchange:
+
+1. Client sends a `TMessage` (type `Call`). The TMessage contains some 
metadata and the name of the method to invoke.
+2. Client sends method arguments (a struct defined by the generate code).
+3. Server sends a `TMessage` (type `Response` or `Exception`) to start the 
response.
+4. Server sends completes response with a struct (a predefined struct or 
one defined by generated code).
+
+The pattern is a simple half duplex protocol where the parties alternate 
in sending a `TMessage` followed by a struct.
+What these are is described below.
+
+Although the standard Apache Thrift Java clients do not support pipelining 
(sending multiple requests without waiting
+for an response), the standard Apache Thrift Java servers do support it.
+
+## TMessage
+
+A *TMessage* contains the following information:
+
+* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and 
`Oneway`.
+* _Sequence id_, an int32 integer.
+* _Name_, a string (can be empty).
+
+The *sequence id* is a simple message id assigned by the client. The 
server will use the same sequence id in the
+TMessage of the response. The client uses this number to detect out of 
order responses. Each client has a int32 field
+which is increased for each message. The sequence id simply wraps around 
when it overflows.
+
+The *name* indicates the service method name to invoke. The server uses 
the same name in the TMessage of the response.
+
+When the *multiplexed protocol* is used, the name contains the service 
name, a colon `:` and the method name. The
+multiplexed protocol is not compatible with other protocols.
+
+The *message type* indicates what kind of message is sent.
+
+Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in 
the protocol exchange). Servers send
+responses with TMessages of type `Exception` or `Reply`.
+
+### Oneway
+
+Type 

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357749#comment-15357749
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user Jens-G commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1036#discussion_r69198940
  
--- Diff: doc/specs/thrift-binary-protocol-encoding.md ---
@@ -0,0 +1,467 @@
+Thrift Protocol Encoding for BinaryProtocol and CompactProtocol
+
+
+Last Modified: 2016-Jun-29
+
+! WARNING !
+
+This document is _work in progress_ and should not (yet) be seen as an 
authoritative source of information.
+
+This text is submitted to the Thrift community for review and improvements.
+
+
+
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+
+
+
+There are many ways to encode Thrift on the wire. This documents focuses 
on the wire encoding for services calls
+(encoding and semantics) in the Thrift older *binary protocol* (which has 
not been documented before) and the
+*compact protocol*. Both the regular socket transport (unframed) and the 
framed transport are described.
+
+Note that no effort is made to group descriptions of behavior of the 
Thrift server and the encodings used in the
+Thrift wire format. The order in which things are described is such that 
you can read the document from top to bottom.
+
+The information here is mostly based on the Java implementation in the 
Apache thrift library (version 0.9.1) and
+[THRIFT-110 A more compact 
format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation 
however,
+should behave the same.
+
+## Message exchange
+
+Both the binary protocol and the compact protocol assume a transport layer 
that exposes a bi-directional byte stream,
+for example a TCP socket. Both use the following message exchange:
+
+1. Client sends a `TMessage` (type `Call`). The TMessage contains some 
metadata and the name of the method to invoke.
+2. Client sends method arguments (a struct defined by the generate code).
+3. Server sends a `TMessage` (type `Response` or `Exception`) to start the 
response.
+4. Server sends completes response with a struct (a predefined struct or 
one defined by generated code).
+
+The pattern is a simple half duplex protocol where the parties alternate 
in sending a `TMessage` followed by a struct.
+What these are is described below.
+
+Although the standard Apache Thrift Java clients do not support pipelining 
(sending multiple requests without waiting
+for an response), the standard Apache Thrift Java servers do support it.
+
+## TMessage
+
+A *TMessage* contains the following information:
+
+* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and 
`Oneway`.
+* _Sequence id_, an int32 integer.
+* _Name_, a string (can be empty).
+
+The *sequence id* is a simple message id assigned by the client. The 
server will use the same sequence id in the
+TMessage of the response. The client uses this number to detect out of 
order responses. Each client has a int32 field
+which is increased for each message. The sequence id simply wraps around 
when it overflows.
+
+The *name* indicates the service method name to invoke. The server uses 
the same name in the TMessage of the response.
+
+When the *multiplexed protocol* is used, the name contains the service 
name, a colon `:` and the method name. The
+multiplexed protocol is not compatible with other protocols.
+
+The *message type* indicates what kind of message is sent.
+
+Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in 
the protocol exchange). Servers send
+responses with TMessages of type `Exception` or `Reply`.
+
+### Oneway
+
+Type 

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357737#comment-15357737
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user Jens-G commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1036#discussion_r69198205
  
--- Diff: doc/specs/thrift-binary-protocol-encoding.md ---
@@ -0,0 +1,467 @@
+Thrift Protocol Encoding for BinaryProtocol and CompactProtocol
+
+
+Last Modified: 2016-Jun-29
+
+! WARNING !
+
+This document is _work in progress_ and should not (yet) be seen as an 
authoritative source of information.
+
+This text is submitted to the Thrift community for review and improvements.
+
+
+
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+
+
+
+There are many ways to encode Thrift on the wire. This documents focuses 
on the wire encoding for services calls
+(encoding and semantics) in the Thrift older *binary protocol* (which has 
not been documented before) and the
+*compact protocol*. Both the regular socket transport (unframed) and the 
framed transport are described.
+
+Note that no effort is made to group descriptions of behavior of the 
Thrift server and the encodings used in the
+Thrift wire format. The order in which things are described is such that 
you can read the document from top to bottom.
+
+The information here is mostly based on the Java implementation in the 
Apache thrift library (version 0.9.1) and
+[THRIFT-110 A more compact 
format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation 
however,
+should behave the same.
+
+## Message exchange
+
+Both the binary protocol and the compact protocol assume a transport layer 
that exposes a bi-directional byte stream,
+for example a TCP socket. Both use the following message exchange:
+
+1. Client sends a `TMessage` (type `Call`). The TMessage contains some 
metadata and the name of the method to invoke.
+2. Client sends method arguments (a struct defined by the generate code).
+3. Server sends a `TMessage` (type `Response` or `Exception`) to start the 
response.
+4. Server sends completes response with a struct (a predefined struct or 
one defined by generated code).
+
+The pattern is a simple half duplex protocol where the parties alternate 
in sending a `TMessage` followed by a struct.
+What these are is described below.
+
+Although the standard Apache Thrift Java clients do not support pipelining 
(sending multiple requests without waiting
+for an response), the standard Apache Thrift Java servers do support it.
+
+## TMessage
+
+A *TMessage* contains the following information:
+
+* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and 
`Oneway`.
+* _Sequence id_, an int32 integer.
+* _Name_, a string (can be empty).
+
+The *sequence id* is a simple message id assigned by the client. The 
server will use the same sequence id in the
+TMessage of the response. The client uses this number to detect out of 
order responses. Each client has a int32 field
+which is increased for each message. The sequence id simply wraps around 
when it overflows.
+
+The *name* indicates the service method name to invoke. The server uses 
the same name in the TMessage of the response.
+
+When the *multiplexed protocol* is used, the name contains the service 
name, a colon `:` and the method name. The
+multiplexed protocol is not compatible with other protocols.
+
+The *message type* indicates what kind of message is sent.
+
+Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in 
the protocol exchange). Servers send
+responses with TMessages of type `Exception` or `Reply`.
+
+### Oneway
+
+Type 

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357734#comment-15357734
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user Jens-G commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1036#discussion_r69197727
  
--- Diff: doc/specs/thrift-binary-protocol-encoding.md ---
@@ -0,0 +1,467 @@
+Thrift Protocol Encoding for BinaryProtocol and CompactProtocol
+
+
+Last Modified: 2016-Jun-29
+
+! WARNING !
+
+This document is _work in progress_ and should not (yet) be seen as an 
authoritative source of information.
+
+This text is submitted to the Thrift community for review and improvements.
+
+
+
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+
+
+
+There are many ways to encode Thrift on the wire. This documents focuses 
on the wire encoding for services calls
+(encoding and semantics) in the Thrift older *binary protocol* (which has 
not been documented before) and the
+*compact protocol*. Both the regular socket transport (unframed) and the 
framed transport are described.
+
+Note that no effort is made to group descriptions of behavior of the 
Thrift server and the encodings used in the
+Thrift wire format. The order in which things are described is such that 
you can read the document from top to bottom.
+
+The information here is mostly based on the Java implementation in the 
Apache thrift library (version 0.9.1) and
+[THRIFT-110 A more compact 
format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation 
however,
+should behave the same.
+
+## Message exchange
+
+Both the binary protocol and the compact protocol assume a transport layer 
that exposes a bi-directional byte stream,
+for example a TCP socket. Both use the following message exchange:
+
+1. Client sends a `TMessage` (type `Call`). The TMessage contains some 
metadata and the name of the method to invoke.
+2. Client sends method arguments (a struct defined by the generate code).
+3. Server sends a `TMessage` (type `Response` or `Exception`) to start the 
response.
+4. Server sends completes response with a struct (a predefined struct or 
one defined by generated code).
+
+The pattern is a simple half duplex protocol where the parties alternate 
in sending a `TMessage` followed by a struct.
+What these are is described below.
+
+Although the standard Apache Thrift Java clients do not support pipelining 
(sending multiple requests without waiting
+for an response), the standard Apache Thrift Java servers do support it.
+
+## TMessage
+
+A *TMessage* contains the following information:
+
+* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and 
`Oneway`.
+* _Sequence id_, an int32 integer.
+* _Name_, a string (can be empty).
+
+The *sequence id* is a simple message id assigned by the client. The 
server will use the same sequence id in the
+TMessage of the response. The client uses this number to detect out of 
order responses. Each client has a int32 field
+which is increased for each message. The sequence id simply wraps around 
when it overflows.
+
+The *name* indicates the service method name to invoke. The server uses 
the same name in the TMessage of the response.
+
+When the *multiplexed protocol* is used, the name contains the service 
name, a colon `:` and the method name. The
+multiplexed protocol is not compatible with other protocols.
+
+The *message type* indicates what kind of message is sent.
+
+Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in 
the protocol exchange). Servers send
+responses with TMessages of type `Exception` or `Reply`.
+
+### Oneway
+
+Type 

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357728#comment-15357728
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user Jens-G commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1036#discussion_r69196978
  
--- Diff: doc/specs/thrift-binary-protocol-encoding.md ---
@@ -0,0 +1,467 @@
+Thrift Protocol Encoding for BinaryProtocol and CompactProtocol
+
+
+Last Modified: 2016-Jun-29
+
+! WARNING !
+
+This document is _work in progress_ and should not (yet) be seen as an 
authoritative source of information.
+
+This text is submitted to the Thrift community for review and improvements.
+
+
+
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+
+
+
+There are many ways to encode Thrift on the wire. This documents focuses 
on the wire encoding for services calls
+(encoding and semantics) in the Thrift older *binary protocol* (which has 
not been documented before) and the
+*compact protocol*. Both the regular socket transport (unframed) and the 
framed transport are described.
+
+Note that no effort is made to group descriptions of behavior of the 
Thrift server and the encodings used in the
+Thrift wire format. The order in which things are described is such that 
you can read the document from top to bottom.
+
+The information here is mostly based on the Java implementation in the 
Apache thrift library (version 0.9.1) and
+[THRIFT-110 A more compact 
format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation 
however,
+should behave the same.
+
+## Message exchange
+
+Both the binary protocol and the compact protocol assume a transport layer 
that exposes a bi-directional byte stream,
+for example a TCP socket. Both use the following message exchange:
+
+1. Client sends a `TMessage` (type `Call`). The TMessage contains some 
metadata and the name of the method to invoke.
+2. Client sends method arguments (a struct defined by the generate code).
+3. Server sends a `TMessage` (type `Response` or `Exception`) to start the 
response.
+4. Server sends completes response with a struct (a predefined struct or 
one defined by generated code).
+
+The pattern is a simple half duplex protocol where the parties alternate 
in sending a `TMessage` followed by a struct.
+What these are is described below.
+
+Although the standard Apache Thrift Java clients do not support pipelining 
(sending multiple requests without waiting
+for an response), the standard Apache Thrift Java servers do support it.
+
+## TMessage
+
+A *TMessage* contains the following information:
+
+* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and 
`Oneway`.
+* _Sequence id_, an int32 integer.
+* _Name_, a string (can be empty).
+
+The *sequence id* is a simple message id assigned by the client. The 
server will use the same sequence id in the
+TMessage of the response. The client uses this number to detect out of 
order responses. Each client has a int32 field
+which is increased for each message. The sequence id simply wraps around 
when it overflows.
+
+The *name* indicates the service method name to invoke. The server uses 
the same name in the TMessage of the response.
+
+When the *multiplexed protocol* is used, the name contains the service 
name, a colon `:` and the method name. The
+multiplexed protocol is not compatible with other protocols.
+
+The *message type* indicates what kind of message is sent.
+
+Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in 
the protocol exchange). Servers send
+responses with TMessages of type `Exception` or `Reply`.
+
+### Oneway
+
+Type 

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357723#comment-15357723
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user Jens-G commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1036#discussion_r69196907
  
--- Diff: doc/specs/thrift-binary-protocol-encoding.md ---
@@ -0,0 +1,467 @@
+Thrift Protocol Encoding for BinaryProtocol and CompactProtocol
+
+
+Last Modified: 2016-Jun-29
+
+! WARNING !
+
+This document is _work in progress_ and should not (yet) be seen as an 
authoritative source of information.
+
+This text is submitted to the Thrift community for review and improvements.
+
+
+
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+
+
+
+There are many ways to encode Thrift on the wire. This documents focuses 
on the wire encoding for services calls
+(encoding and semantics) in the Thrift older *binary protocol* (which has 
not been documented before) and the
+*compact protocol*. Both the regular socket transport (unframed) and the 
framed transport are described.
+
+Note that no effort is made to group descriptions of behavior of the 
Thrift server and the encodings used in the
+Thrift wire format. The order in which things are described is such that 
you can read the document from top to bottom.
+
+The information here is mostly based on the Java implementation in the 
Apache thrift library (version 0.9.1) and
+[THRIFT-110 A more compact 
format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation 
however,
+should behave the same.
+
+## Message exchange
+
+Both the binary protocol and the compact protocol assume a transport layer 
that exposes a bi-directional byte stream,
+for example a TCP socket. Both use the following message exchange:
+
+1. Client sends a `TMessage` (type `Call`). The TMessage contains some 
metadata and the name of the method to invoke.
+2. Client sends method arguments (a struct defined by the generate code).
+3. Server sends a `TMessage` (type `Response` or `Exception`) to start the 
response.
+4. Server sends completes response with a struct (a predefined struct or 
one defined by generated code).
+
+The pattern is a simple half duplex protocol where the parties alternate 
in sending a `TMessage` followed by a struct.
+What these are is described below.
+
+Although the standard Apache Thrift Java clients do not support pipelining 
(sending multiple requests without waiting
+for an response), the standard Apache Thrift Java servers do support it.
+
+## TMessage
+
+A *TMessage* contains the following information:
+
+* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and 
`Oneway`.
+* _Sequence id_, an int32 integer.
+* _Name_, a string (can be empty).
+
+The *sequence id* is a simple message id assigned by the client. The 
server will use the same sequence id in the
+TMessage of the response. The client uses this number to detect out of 
order responses. Each client has a int32 field
+which is increased for each message. The sequence id simply wraps around 
when it overflows.
+
+The *name* indicates the service method name to invoke. The server uses 
the same name in the TMessage of the response.
+
+When the *multiplexed protocol* is used, the name contains the service 
name, a colon `:` and the method name. The
+multiplexed protocol is not compatible with other protocols.
+
+The *message type* indicates what kind of message is sent.
+
+Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in 
the protocol exchange). Servers send
+responses with TMessages of type `Exception` or `Reply`.
+
+### Oneway
+
+Type 

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[Erik van Oosten (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15355043#comment-15355043
 ] 

Erik van Oosten commented on THRIFT-3867:
-

Pull request in https://github.com/apache/thrift/pull/1036.

> Specify BinaryProtocol and CompactProtocol
> --
>
> Key: THRIFT-3867
> URL: https://issues.apache.org/jira/browse/THRIFT-3867
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation
>Reporter: Erik van Oosten
>
> It would be nice when the protocol(s) would be specified somewhere. This 
> should improve communication between developers, but also opens the way for 
> alternative implementations so that Thrift can thrive even better.
> I have a fairly complete description of the BinaryProtocol and 
> CompactProtocol which I will submit as a patch for further review and 
> discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15355042#comment-15355042
 ] 

ASF GitHub Bot commented on THRIFT-3867:


GitHub user erikvanoosten opened a pull request:

https://github.com/apache/thrift/pull/1036

THRIFT-3867 Specify BinaryProtocol and CompactProtocol

First version of a specification of the binary protocol and compact 
protocol. Please review and comment.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/erikvanoosten/thrift THRIFT-3867

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1036.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1036


commit c6cb4d14a0c915001f4eb46e8e8fd822b9355e51
Author: Erik van Oosten 
Date:   2016-06-29T11:24:00Z

THRIFT-3867 first version of a specification of the binary protocol and 
compact protocol.




> Specify BinaryProtocol and CompactProtocol
> --
>
> Key: THRIFT-3867
> URL: https://issues.apache.org/jira/browse/THRIFT-3867
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation
>Reporter: Erik van Oosten
>
> It would be nice when the protocol(s) would be specified somewhere. This 
> should improve communication between developers, but also opens the way for 
> alternative implementations so that Thrift can thrive even better.
> I have a fairly complete description of the BinaryProtocol and 
> CompactProtocol which I will submit as a patch for further review and 
> discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)