[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=15509129#comment-15509129
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user erikvanoosten commented on the issue:

https://github.com/apache/thrift/pull/1036
  
Feel free to take it. I won't support it anymore though.


> 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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=15506237#comment-15506237
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user erikvanoosten closed the pull request at:

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&focusedCommentId=15506236#comment-15506236
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user erikvanoosten commented on the issue:

https://github.com/apache/thrift/pull/1036
  
Closing this due to lack of interest of repo owners.


> 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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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`.
+
+### Onewa

[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&focusedCommentId=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`.
+
+### Onewa

[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&focusedCommentId=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`.
+
+### Onewa

[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&focusedCommentId=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&focusedCommentId=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
+

[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&focusedCommentId=15357770#comment-15357770
 ] 

ASF GitHub Bot commented on THRIFT-3867:


Github user Jens-G commented on the issue:

https://github.com/apache/thrift/pull/1036
  
Overall pretty neat. I still have a few complaints.

1. The document repeats a lot of stuff that can be found elsewhere, e.g. in 
the Thrift Whitepaper. There is nothing per se wrong with repeating stuff, but 
from my feeling it makes the spec a bit bloaty. 

2. I think the structure should be revised grossly. No need to panic, I'm 
going to explain what I have in mind. By looking at the bits and bytes the 
reader may miss an important point: The order of data is always the same and 
entitrely Independent from the wire format, because that's the way Thrift 
Protocols work. 

 * At the first level we have messages. They have a certain structure.

 * at the next level, a particular data item has a certain structure: a  
map always consists of two types and a count, plus the elements. That does not 
change between protocols. What changes is the way how a particular protocol 
organizes the data onto the wire.

 * and one level deeper we are at what I mean by revising the structure: I 
would not constantly jump back and forth between protocols to explain structs, 
lists, sets, integers, etc. Instead, there should be one chapter focusing on 
binary, and another one for compact. That makes it much easier 
  a) for the reader who is usually interested in only one protocol at a 
time, and 
  b) for future maintainers to add more protocols, such as JSON.




> 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&focusedCommentId=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
+

[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&focusedCommentId=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
+

[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&focusedCommentId=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
+

[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&focusedCommentId=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
+

[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&focusedCommentId=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
+

[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&focusedCommentId=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&focusedCommentId=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)