Re: [rap-dev] Objects vs. Arrays for operations in the protocol

[Ralf Sternberg <rsternberg@xxxxxxxxxxxxxxxxx>]

Thank you all for your comments and insights.

We've heard some concerns about extensibility and API evolution - I've
had these concerns too, but I really could not make out any realistic
extension that could be impeded by this change. Since the change only
affects the format of the operations itself, i.e. it is kind of a
"meta format", we still have options to evolve the protocol. We can,
for example, add a parameter to an operation, make an existing
parameter optional, or even create additional operations. But the
cases for those extensions seem to be very limited. Thus I think that
the benefits outweigh the risk.

I've also got some positive feedback from Jordi, Tim, and Ivan. So
we're going to make the change, and we should do it quickly to have it
ready for M6 and EclipseCon. I've opened bug 371252 [1], if there is
need for a technical discussion, let's continue it there.

@Holger: that's an interesting point, so we'd have to make the last
parameter optional in this case or require an empty object. Since it's
the last parameter, I think it should be optional. We don't have to
check the array length. Accessing an invalid index of an array in
JavaScript is not an error, it yields undefined.

Cheers, Ralf

[1] Bug 371252: [Protocol] Use JSON arrays for operations
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=371252


On Thu, Feb 2, 2012 at 18:06, Holger Staudacher
<hstaudacher@xxxxxxxxxxxxxxxxx> wrote:
> 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
>
>
> _______________________________________________
> rap-dev mailing list
> rap-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rap-dev
>