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 <[email protected]> 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 >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/rap-dev > > _______________________________________________ > rap-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/rap-dev
_______________________________________________ rap-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/rap-dev
