[jira] [Comment Edited] (BOOKKEEPER-309) Protocol changes in hedwig to support JMS spec

["Ivan Kelly (JIRA)" <ji...@apache.org>]

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

Ivan Kelly edited comment on BOOKKEEPER-309 at 6/25/12 2:04 PM:
----------------------------------------------------------------

I would prefer not to put anything JMS specific into the hedwig protocol. If JMS is running on top, of hedwig, it should run on top. There shouldn't be cross contamination between the protocols. I think this is quite easy though. 

JmsBodyType is an enum. It can be very easily implemented as a byte in the metadata, and a byte->enum mapping used on the jms client.

I think there should be only 1 metadata in Message, which is a repeated of a generic 'KeyValue' type. 
{code}
message KeyValue {
    enum ValueType {
        BOOLEAN = 1;
        BYTE = 2;
        SHORT = 3;
        INT = 4;
        LONG = 5;
        FLOAT = 6;
        DOUBLE = 7;
        STRING = 8;
    };
    required ValueType type = 1;
    required string key = 2;

    optional bool booleanValue = 3;
    optional sint32 byteValue = 4;
    ...
}
{code}
In fact, I'm inclined to think there should only be a 'bytes' value type, and leave it up to the application to decode it correctly. Sijie was talking about adding metadata recently, so we should also discuss this with him.

body cannot be changed from required to optional unfortunately, as this is a BC break. However, we can have a 'bodyEmpty' boolean metadata value, which the client can interpret to mean the same thing.

1 final proceedure point. When you do a git diff, use (--no-prefix). It means that a patch will apply with patch -p0, which is a convention we prefer (not that it's particularly better than -p1, but its like driving on one side of the road).

                
      was (Author: ikelly):
    I would prefer not to put anything JMS specific into the hedwig protocol. If JMS is running on top, of hedwig, it should run on top. There shouldn't be cross contamination between the protocols. I think this is quite easy though. 

JmsBodyType is an enum. It can be very easily implemented as a byte in the metadata, and a byte->enum mapping used on the jms client.

I think there should be only 1 metadata in Message, which is a repeated of a generic 'KeyValue' type. 
{code}
message KeyValue {
    enum ValueType {
        BOOLEAN = 1;
        BYTE = 2;
        SHORT = 3;
        INT = 4;
        LONG = 5;
        FLOAT = 6;
        DOUBLE = 7;
        STRING = 8;
    };
    required ValueType type = 1;
    required string key = 2;

    optional bool booleanValue = 3;
    optional sint32 byteValue = 4;
    ...
}
In fact, I'm inclined to think there should only be a 'bytes' value type, and leave it up to the application to decode it correctly. Sijie was talking about adding metadata recently, so we should also discuss this with him.

body cannot be changed from required to optional unfortunately, as this is a BC break. However, we can have a 'bodyEmpty' boolean metadata value, which the client can interpret to mean the same thing.

1 final proceedure point. When you do a git diff, use (--no-prefix). It means that a patch will apply with patch -p0, which is a convention we prefer (not that it's particularly better than -p1, but its like driving on one side of the road).

                  
> Protocol changes in hedwig to support JMS spec
> ----------------------------------------------
>
>                 Key: BOOKKEEPER-309
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-309
>             Project: Bookkeeper
>          Issue Type: Sub-task
>            Reporter: Mridul Muralidharan
>         Attachments: hedwig-protocol.patch
>
>
> JMS spec compliance requires three changes to the protocol.
> a) Support for message properties.
> b) Make body optional (message contains only properties).
> c) Return the published message's seq-id in the response.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira