Quantcast

RPC: We need a standard compliant way to serialize dates

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RPC: We need a standard compliant way to serialize dates

Fabian Jakobs
Administrator
Hi,

Yesterday I've landed a commit, which adds native JSON support to
qooxdoo. There is a new class qx.lang.Json, which has exactly the same
interface as the JSON object defined in the EcmaScript 5 specification
<https://developer.mozilla.org/En/Using_native_JSON>. All new browsers
like Firefox 3.5, Internet Explorer 8, Opera 10.5 or Safari 4 support it
natively. In browsers without native JSON support a modified version of
Douglas Crockford's json2 is used. This is great news because parsing
and serializing JSON is a lot faster on those browsers.

BUT

we cannot deprecate the old implementation yet. The qooxdoo JSON
implementation has historically maintained an incompatible JSON
extension to support dates. The idea was let "eval" create the date
instances:

qx.util.Json.stringify({ date: new Date(123)})   --> {"date":new
Date(Date.UTC(1970,0,1,0,0,0,0))}

While it probably was a good idea back then, it is a problem now because
we cannot make the browser's JSON object emit or parse this:

JSON.stringify{ date: new Date(123)} --> {"date":"1970-01-01T00:00:00.000Z"}

For the server side we have the same problem. If we support this e.g. in
PHP we cannot use PHP's buildin JSON support, which means a severe
performance hit.


Since the RPC code is the only code depending on this feature I would
like to know from the RPC authors:

1. Wouldn't dates represented as ISO strings be sufficient? Do you think
we need a special date extension?
2. If we find a standard compliant way to serialize dates, would you
update your backend code?
3. Do you think everything is fine and we should just keep both JSON
implementations?

I'm really interested in your feedback,

Best Fabian

--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RPC: We need a standard compliant way to serialize dates

Jean-Baptiste BRIAUD -- Novlog

On Jan 18, 2010, at 13:32 , Fabian Jakobs wrote:

> Hi,
>
> Yesterday I've landed a commit, which adds native JSON support to
> qooxdoo. There is a new class qx.lang.Json, which has exactly the same
> interface as the JSON object defined in the EcmaScript 5 specification
> <https://developer.mozilla.org/En/Using_native_JSON>. All new browsers
> like Firefox 3.5, Internet Explorer 8, Opera 10.5 or Safari 4 support it
> natively. In browsers without native JSON support a modified version of
> Douglas Crockford's json2 is used. This is great news because parsing
> and serializing JSON is a lot faster on those browsers.

super good news !!

>
> BUT
>
> we cannot deprecate the old implementation yet. The qooxdoo JSON
> implementation has historically maintained an incompatible JSON
> extension to support dates. The idea was let "eval" create the date
> instances:
>
> qx.util.Json.stringify({ date: new Date(123)})   --> {"date":new
> Date(Date.UTC(1970,0,1,0,0,0,0))}
>
> While it probably was a good idea back then, it is a problem now because
> we cannot make the browser's JSON object emit or parse this:
>
> JSON.stringify{ date: new Date(123)} --> {"date":"1970-01-01T00:00:00.000Z"}
>
> For the server side we have the same problem. If we support this e.g. in
> PHP we cannot use PHP's buildin JSON support, which means a severe
> performance hit.

Another good argument in favor of the ISO string and stick to JSON standard.

>
>
> Since the RPC code is the only code depending on this feature I would
> like to know from the RPC authors:
>
> 1. Wouldn't dates represented as ISO strings be sufficient?
I think, if possible, we should strictly respect the JSON standard.
For our Java backend, an ISO string would be fine, we will be able to convert from and to that ISO String (or any other) using date formatter.

> Do you think
> we need a special date extension?
I'm not sure about what you are calling an extension, but then, no need for something special.

> 2. If we find a standard compliant way to serialize dates, would you
> update your backend code?
Sure we'll update our future contrib so we'll be able to remove special case in the json.org code we had to made specific change to it.
The only difficult point is that we are still in 0.8 and I don't know how long it will take to test against the qx trunk ...

> 3. Do you think everything is fine and we should just keep both JSON
> implementations?
On client side or server side ?
On client side, if we could use the super speed implem, it would be great.
If we want to keep both, we could standardize a meta RPC call where the backend implem have to return what future RPC call implem will be.
Something where the backend could inform the front end that it is fully standard or not for JSON date ...
WIthout that call, the default (standard ?) implem will be used. This could allow retro compatible via only that small addition to the backend.



------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RPC: We need a standard compliant way to serialize dates

Derrell Lipman
In reply to this post by Fabian Jakobs
On Mon, Jan 18, 2010 at 07:32, Fabian Jakobs <[hidden email]> wrote:
Since the RPC code is the only code depending on this feature I would
like to know from the RPC authors:

1. Wouldn't dates represented as ISO strings be sufficient? Do you think
we need a special date extension?
2. If we find a standard compliant way to serialize dates, would you
update your backend code?
3. Do you think everything is fine and we should just keep both JSON
implementations?

I'm really interested in your feedback,

Andreas J. and I had long conversations about this extension many years ago, as part of a standardization of qooxdoo JSON-RPC implementations (Java and PHP, at the time). Since then, there has been ongoing discussion about the optimizations that could be made by eliminating the extension. The PHP JSON-RPC server has, in fact, a flag to disable the extension and use the native JSON formatters/parsers. That requires a cooperative agreement between the server and all of its clients that the clients will not try to use the qooxdoo date format (i.e. they will not format Date objects). I don't believe that there are currently any properties in the client code to specify whether special Date processing is required.

In more recent discussions, we've talked about the concept of JSON-RPC server extensions. I've recommended that the Date processing be implemented as an extension, and the client be able to determine whether the server supports that extension. I continue to support this recommendation. Applications have long been provided with Date processing capability, and it's a worthwhile capability. With the addition of a property in the RPC class, we could easily switch between the efficient, built-in JSON formatters/parsers, and the less-efficient, but extensible, JavaScript ones currently being used.

In answer to your specific questions:

1. Dates represented as ISO strings must be converted by the application, thus it's much less desirable than having Date objects once parsing is complete.

2. Sure, I'd be glad to support standard-compliant date serialization. AFAIK, though, there isn't any.

3. I don't think everything is fine, but I do think that at least until we come up with a better solution, what I proposed above, with a property to select the internal or external fromater/parser and a queriable extension at the server solves the problem.

Derrell


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RPC: We need a standard compliant way to serialize dates

oetiker
In reply to this post by Fabian Jakobs
Hi Fabian,

Today Fabian Jakobs wrote:

> Hi,
>
> Yesterday I've landed a commit, which adds native JSON support to
> qooxdoo. There is a new class qx.lang.Json, which has exactly the same
> interface as the JSON object defined in the EcmaScript 5 specification
> <https://developer.mozilla.org/En/Using_native_JSON>. All new browsers
> like Firefox 3.5, Internet Explorer 8, Opera 10.5 or Safari 4 support it
> natively. In browsers without native JSON support a modified version of
> Douglas Crockford's json2 is used. This is great news because parsing
> and serializing JSON is a lot faster on those browsers.
>
> BUT
>
> we cannot deprecate the old implementation yet. The qooxdoo JSON
> implementation has historically maintained an incompatible JSON
> extension to support dates. The idea was let "eval" create the date
> instances:
>
> qx.util.Json.stringify({ date: new Date(123)})   --> {"date":new
> Date(Date.UTC(1970,0,1,0,0,0,0))}
>
> While it probably was a good idea back then, it is a problem now because
> we cannot make the browser's JSON object emit or parse this:
>
> JSON.stringify{ date: new Date(123)} --> {"date":"1970-01-01T00:00:00.000Z"}
>
> For the server side we have the same problem. If we support this e.g. in
> PHP we cannot use PHP's buildin JSON support, which means a severe
> performance hit.
>
>
> Since the RPC code is the only code depending on this feature I would
> like to know from the RPC authors:
>
> 1. Wouldn't dates represented as ISO strings be sufficient? Do you think
> we need a special date extension?

since perl does not have a 'native' date type anyway, this should
do fine ... on the other something already 'split' into an array or
a map might be quicker and less problematic than parsing an ISO date.

> 2. If we find a standard compliant way to serialize dates, would you
> update your backend code?

sure

> 3. Do you think everything is fine and we should just keep both JSON
> implementations?

nope ... :-)

cheers
tobi
>
> I'm really interested in your feedback,
>
> Best Fabian
>
>

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [hidden email] ++41 62 775 9902 / sb: -9900

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RPC: We need a standard compliant way to serialize dates

Helder Magalhães
In reply to this post by Fabian Jakobs

Hi everyone,



Fabian Jakobs wrote:
>
> Yesterday I've landed a commit, which adds native JSON support to
> qooxdoo. [...] This is great news because parsing
> and serializing JSON is a lot faster on those browsers.
>

Cool! :-)



Fabian Jakobs wrote:
>
> BUT
> we cannot deprecate the old implementation yet.
>

I knew that this was too good to be true... :-D
(Just kidding, I was already aware of this limitation.)



Fabian Jakobs wrote:
>
> Since the RPC code is the only code depending on this feature I would
> like to know from the RPC authors:
>
> 1. Wouldn't dates represented as ISO strings be sufficient? Do you think
> we need a special date extension?
>

I'm not sure if we need a special date extension. In our (custom) RPC
implementation, we don't use this extension but do pass on dates back and
forward...

(I already stated something related in the bug tracker [1] but here goes:)
We have high accuracy requirements for dates, so we use a two integer array:
first meaning seconds since 01/01/1970 and the second meaning the fraction
within the second. As usual, this has positive and negative aspects:
 (+) It's damn fast to turn such an array into a JavaScript Date object;
 (-) It's (very) hard to read to humans;
 (-) There is no class hinting stating to the parser that this is actually a
date. The client/server needs to know implicitly where are these special
arrays located within the received data;
 (-) This will explode in 2038, where the first integer will overflow.
Although JavaScript implementations are required to use 64-bit, tests I've
done a few years ago have revealed that this isn't fulfilled for most. Of
course this gives us a lot of time to workaround a solution, but it seemed
fine to share as we're at it. :-)

In the same bug report it's suggested that data binding features of qooxdoo
would be used to cover this caveat, which I though to be an elegant
solution! ;-)



Fabian Jakobs wrote:
>
> 2. If we find a standard compliant way to serialize dates, would you
> update your backend code?
>

Yes. Sniffing strings for ISO dates would also sound good, but I'm afraid it
will mean an important overhead when there are large/complex objects flying
over back and forward... :-|



Fabian Jakobs wrote:
>
> 3. Do you think everything is fine and we should just keep both JSON
> implementations?
>

Keeping both implementations means more code to maintain and probably, in
the long run, more bugs to fight with... :-(



Fabian Jakobs wrote:
>
> I'm really interested in your feedback,
>
> Best Fabian
>

Cheers,
 Helder


[1] http://bugzilla.qooxdoo.org/show_bug.cgi?id=1400#c14
--
View this message in context: http://old.nabble.com/RPC%3A-We-need-a-standard-compliant-way-to-serialize-dates-tp27210452p27214978.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RPC: We need a standard compliant way to serialize dates

Petr Kobalíček
In reply to this post by Fabian Jakobs
I'm also voting for removing this extension, it makes qooxdoo-json-rpc
incompatible with everything.

On Mon, Jan 18, 2010 at 1:32 PM, Fabian Jakobs <[hidden email]> wrote:

> Hi,
>
> Yesterday I've landed a commit, which adds native JSON support to
> qooxdoo. There is a new class qx.lang.Json, which has exactly the same
> interface as the JSON object defined in the EcmaScript 5 specification
> <https://developer.mozilla.org/En/Using_native_JSON>. All new browsers
> like Firefox 3.5, Internet Explorer 8, Opera 10.5 or Safari 4 support it
> natively. In browsers without native JSON support a modified version of
> Douglas Crockford's json2 is used. This is great news because parsing
> and serializing JSON is a lot faster on those browsers.
>
> BUT
>
> we cannot deprecate the old implementation yet. The qooxdoo JSON
> implementation has historically maintained an incompatible JSON
> extension to support dates. The idea was let "eval" create the date
> instances:
>
> qx.util.Json.stringify({ date: new Date(123)})   --> {"date":new
> Date(Date.UTC(1970,0,1,0,0,0,0))}
>
> While it probably was a good idea back then, it is a problem now because
> we cannot make the browser's JSON object emit or parse this:
>
> JSON.stringify{ date: new Date(123)} --> {"date":"1970-01-01T00:00:00.000Z"}
>
> For the server side we have the same problem. If we support this e.g. in
> PHP we cannot use PHP's buildin JSON support, which means a severe
> performance hit.
>
>
> Since the RPC code is the only code depending on this feature I would
> like to know from the RPC authors:
>
> 1. Wouldn't dates represented as ISO strings be sufficient? Do you think
> we need a special date extension?
> 2. If we find a standard compliant way to serialize dates, would you
> update your backend code?
> 3. Do you think everything is fine and we should just keep both JSON
> implementations?
>
> I'm really interested in your feedback,
>
> Best Fabian
>
> --
> Fabian Jakobs
> JavaScript Framework Developer
>
> 1&1 Internet AG - Web Technologies
> Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
> Telefon: +49 721 91374-6784
> [hidden email]
>
> Amtsgericht Montabaur / HRB 6484
> Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
> Aufsichtsratsvorsitzender: Michael Scheeren
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>



--
Best regards
- Petr Kobalicek <http://kobalicek.com>

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RPC: We need a standard compliant way to serialize dates

Fabian Jakobs
Administrator
In reply to this post by Fabian Jakobs
Hi,

thank you for the valuable feedback. We plan to work on the RPC client
in the new future. This is what we have in mind right now:

Our goal is to build a JSON-RPC client, which fully implements the
JSON-RPC protocol version 1 and 2 without any proprietary protocol
extensions. We think proprietary protocol extensions make it much harder
to implement complaint backends and to be interoperable with existing
JSON-RPC implementations. JSON-RPC version 2 support is interesting
because it adds support for batching requests and named parameters.

Specific deficiencies of the current implementation are:

- it only supports JSON-RPC version 1
- it adds an proprietary "service" argument to each request, which is
supposed to select the service. The standard way would be to
differentiate services by their URL end points.
- cross domain support is proprietary. We have to investigate the right
way to do this.
- non JSON compliant encoding of dates. We feel that de-/encoding of
complex data types like dates is in the domain of the application
developer and should not be part of the transfer protocol.

The consequences for the backends would be:

- The "service" argument should be ignored
- encode dates as valid JSON
- optional support for cross site requests

What are your ideas about this?

Best Fabian

--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RPC: We need a standard compliant way to serialize dates

Jean-Baptiste BRIAUD -- Novlog

On Jan 19, 2010, at 16:52 , Fabian Jakobs wrote:

> Hi,
>
> thank you for the valuable feedback. We plan to work on the RPC client
> in the new future. This is what we have in mind right now:
>
> Our goal is to build a JSON-RPC client, which fully implements the
> JSON-RPC protocol version 1 and 2 without any proprietary protocol
> extensions. We think proprietary protocol extensions make it much harder
> to implement complaint backends and to be interoperable with existing
> JSON-RPC implementations.
yes.

> JSON-RPC version 2 support is interesting
> because it adds support for batching requests and named parameters.
>
> Specific deficiencies of the current implementation are:
>
> - it only supports JSON-RPC version 1
> - it adds an proprietary "service" argument to each request, which is
> supposed to select the service. The standard way would be to
> differentiate services by their URL end points.
> - cross domain support is proprietary. We have to investigate the right
> way to do this.
> - non JSON compliant encoding of dates. We feel that de-/encoding of
> complex data types like dates is in the domain of the application
> developer and should not be part of the transfer protocol.
>
> The consequences for the backends would be:
>
> - The "service" argument should be ignored
OK and replaced the argument by URL end point as it sound like JSON standard RPC. Am I right ? (I never read JSON RPC spec).
> - encode dates as valid JSON
OK.
> - optional support for cross site requests
OK for optional behavior.
>
> What are your ideas about this?
What about version 2 new features ?

- What about what you called "batching request" ? I don't know what it is but it look like part of the spec ?

- Named parameter will make it difficult and probably impossible for backend language where method parameter are passed only by position like Java.
We might design some annotation for that but it would break backend simplicity as currently, for a Java backend, nothing special is needed.
So, for named parameter features, I would ask for more information.

>
> Best Fabian
>
> --
> Fabian Jakobs
> JavaScript Framework Developer
>
> 1&1 Internet AG - Web Technologies
> Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
> Telefon: +49 721 91374-6784
> [hidden email]
>
> Amtsgericht Montabaur / HRB 6484
> Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
> Aufsichtsratsvorsitzender: Michael Scheeren
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RPC: We need a standard compliant way to serialize dates

Fabian Jakobs
Administrator
Hi,

>> Specific deficiencies of the current implementation are:
>>
>> - it only supports JSON-RPC version 1
>> - it adds an proprietary "service" argument to each request, which is
>> supposed to select the service. The standard way would be to
>> differentiate services by their URL end points.
>> - cross domain support is proprietary. We have to investigate the right
>> way to do this.
>> - non JSON compliant encoding of dates. We feel that de-/encoding of
>> complex data types like dates is in the domain of the application
>> developer and should not be part of the transfer protocol.
>>
>> The consequences for the backends would be:
>>
>> - The "service" argument should be ignored
>>    
> OK and replaced the argument by URL end point as it sound like JSON standard RPC. Am I right ? (I never read JSON RPC spec).
>  
This is my interpretation of the spec because in the spec is no such
thing as the "service" argument. To me it would be natural to
distinguish services by their URL.

>> - encode dates as valid JSON
>>    
> OK.
>  
>> - optional support for cross site requests
>>    
> OK for optional behavior.
>  
>> What are your ideas about this?
>>    
> What about version 2 new features ?
>  
Since the client will continue to support JSON-RPC v1 the backend does
not have to implement JSON-RPC v2. Although it would be nice if the
backends would support it.
> - What about what you called "batching request" ? I don't know what it is but it look like part of the spec
>  
Batching means that you can send an array of requests to the server and
receive an array of results as response. This can be uses to do multiple
calls with only one HTTP request.
> - Named parameter will make it difficult and probably impossible for backend language where method parameter are passed only by position like Java.
> We might design some annotation for that but it would break backend simplicity as currently, for a Java backend, nothing special is needed.
> So, for named parameter features, I would ask for more information.
If you want to support named parameters in Java you will have to add
annotations to the arguments since you cannot read them using
reflection. I have actually found a way to read the names
<http://www.squarebits.com/?p=25> but this is a little esoteric and
requires that the code is compiled in debugging mode. IMHO this is
something the user of your backend code has to decide. If he wants named
parameters he has to add the annotations. If the annotations are missing
you could return an "Invalid params". I'm not sure if this is according
to the spec but it would make sense to me.

Best Fabian

--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Loading...