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

ASF GitHub Bot commented on THRIFT-3706:
----------------------------------------

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

    https://github.com/apache/thrift/pull/1200#discussion_r102357395
  
    --- Diff: lib/java/test/org/apache/thrift/test/TestServer.java ---
    @@ -190,7 +193,9 @@ public static void main(String [] args) {
             if (protocol_type.equals("binary")) {
             } else if (protocol_type.equals("compact")) {
             } else if (protocol_type.equals("json")) {
    -        } else if (protocol_type.equals("multiplexed")) {
    +        } else if (protocol_type.equals("multi")) {
    --- End diff --
    
    I did it this way to work within the spec:impl naming convention that 
currently exists in make cross.  See tests.json, specifically "binary:accel" or 
"compact:accelc".  I wanted to follow the pattern that already existed in the 
test suite so we have a single use pattern, not two.  In the end the behavior 
is mostly the same, except by using "multi:binary" on the java server and 
"binary:multi" on the c_glib client, we end up testing:  c_glib (binary client) 
=> java (multi server) as well as c_glib (multi client wrapping binary) => java 
(multi server wrapping binary).  Using the "multiplexed-binary" naming 
convention would not have leveraged the existing logic in crosstest/collect.py 
to make this happen.


> There's no support for Multiplexed protocol on c_glib library
> -------------------------------------------------------------
>
>                 Key: THRIFT-3706
>                 URL: https://issues.apache.org/jira/browse/THRIFT-3706
>             Project: Thrift
>          Issue Type: Improvement
>          Components: C glib - Library
>    Affects Versions: 0.9.3
>            Reporter: Gonzalo Aguilar
>            Assignee: James E. King, III
>             Fix For: 0.11.0
>
>
> There's no multiplexed protocol. 
> I will implement the same way it's done in Java an C++



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to