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=371252
>
>
> On Thu, Feb 2, 2012 at 18:06, Holger Staudacher
> <[email protected]> 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 <[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
>>
> _______________________________________________
> rap-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/rap-dev
Holger Staudacher
Follow me: @hstaudacher
Innoopract Informationssysteme GmbH
[email protected]
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
====================================================================
_______________________________________________
rap-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/rap-dev
