| Hi Ralf, I know it doesn't throw an error. Maybe I didn't express myself clear enough regarding this concern. With an optional argument you always have to handle it this kind of way:
var arg = array[ 4 ]; if( arg ) { …. }
Within a protocol message this is smell to me because I think a protocol message should be straightforward. An interpreter should not be in a need to make those checks, it's only purpose should be to parse and delegate message content.
But as I said before, this is really a minor concern and I wrote this reply only to make my point clear.
Cheers Holger
On Feb 13, 2012, at 1:01 PM, Ralf Sternberg wrote: 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=371252On 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
_______________________________________________ rap-dev mailing list rap-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/rap-dev
Holger Staudacher
Follow me: @hstaudacher
Innoopract Informationssysteme GmbH
Tel: +49 721 - 66 47 33 - 0
Fax: +49 721 - 66 47 33 29
========================= Legal Disclaimer =========================
According to Section 80 of the German Corporation Act Innoopract
Informationssysteme GmbH must indicate the following information:
Address: Lammstr. 21, 76133 Karlsruhe Germany
General Manager: Jochen Krause
Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883
====================================================================
|
