[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rap-dev] Objects vs. Arrays for operations in the protocol

I like this idea very much. One thing that came into my mind when reading the new definition was the following:

The initial properties in the create operation are optional, right? So, when using the object approach we can simply check if the propery exist, with the array approach we have to scan the length of the array for checking if initial properties exist. This sound a little bit messy to me. But this is really the only thing that came into my mind that speaks against the new format. 

The extensibility topic doesnt matter from my point of view. So, + 1 from my side ;)

Cheers Holger

On 24.01.2012, at 16:16, Austin Riddle <austin.riddle@xxxxxxxx> wrote:

I absolutely agree with this approach and definitely consider the new definition to be more readable.
With a proper metadata definition in the Wiki or elsewhere, I don't see the need for the protocol to be more verbose.

On 1/24/2012 1:42 AM, Ralf Sternberg wrote:
Hi all,

after some month of experience with the new protocol, and working on a
format definition [1], I have to say that I'm mostly very happy with
the result, but I've also been thinking about a possible change.
Before we're going to present the protocol in talks and blogs, and
finalize the definition in the upcoming release, I'd like to take the
opportunity to discuss this idea.

The thing that dissatisfies me is the verbosity of the protcol. When
skimming over a protocol message, I find that all these repeating
property names like "action: ...", "target: ...", "properties: ..."
etc. are distracting and do not carry useful information.

My point is that if we used arrays instead of objects, the protocol
would not lose expressiveness but even gain readibility. Every single
operation type would have a fixed argument list, and the number of
arguments for the five op types is so small that they cannot be mixed
up. To give an example, instead of

  { "action": "destroy", "target": "w23" },
  { "action": "set", "target": "w24", "properties": { "visibility": false } }

it would just be

  [ "destroy", "w23" ],
  [ "set", "w24", { "visibility": false } ]

I'll also attach a short example messages in both formats. The
definitions [1] would then look like:

<CreateOperation> ::= [ "create", <TargetId>, <TypeName>, <IntitialProperties> ]
<SetOperation> ::= [ "set", <TargetId>, <Properties> ]
<CallOperation> ::= [ "call", <TargetId>, <MethodName>, <Parameters> ]
<ListenOperation> ::= [ "listen", <TargetId>, <Properties> ]
<DestroyOperation> ::= [ "destroy", <TargetId> ]

I've replayed a JMeter recording with this change in place and found
that this notation reduces the protocol messages in total by 22.5%,
with gzip compression this gain is reduced to 3.5%. I'm not so much
making the case for performance, more for clarity. However, when
looking at the popularity of binary protocols in the mobile world, the
current protocol could appear a bit wasteful.

I admit that I like the [ opcode, parameter, ... ] format as it
resembles lambda expressions and also the way operations are written
in assembler code. One advantage of using objects may be its
extensibility - we could easily add and remove parameters to objects
over time, but we can only append parameters when using arrays.
However, given the few operation types and parameters we currently
need for the entire server-client communication, this point seems a
bit hypothetical.

What do you think?

Cheers, Ralf


[1] http://wiki.eclipse.org/RAP/Protocol


_______________________________________________
rap-dev mailing list
rap-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rap-dev

_______________________________________________
rap-dev mailing list
rap-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rap-dev