[infinispan-dev] Remote execute null return (ISPN-6406)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Remote execute null return (ISPN-6406)

Galder Zamarreño
Hi all,

A Hot Rod protocol change might be required as a result of [1].

In essence, the Hot Rod protocol does not specify how remote exec calls that return null should respond back to the client [2].

Returning an empty byte[] won't cut it since returning an empty String would be represented that way, and that's different to null.

I don't know how this could be handled without modifying the protocol, any ideas?

If modifying the protocol, adding a new status code would be a way to handle it.

Thoughts?

[1] https://issues.jboss.org/browse/ISPN-6406
[2] http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_hot_rod_protocol_2_0
--
Galder Zamarreño
Infinispan, Red Hat


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Remote execute null return (ISPN-6406)

Sebastian Laskawiec
I think this is pretty common problem [3]. 

On the other hand most of the users won't be interested in distinguishing nulls from empty strings (at least in my opinion). So how about leaving it as is by default and creating some configuration parameter for using new status code as you suggested (just in case someone would have to distinguish those two).

This way we would be somewhat backwards compatible and we would have a rescue option for some users who would need this feature.

On Tue, Apr 19, 2016 at 6:31 PM, Galder Zamarreño <[hidden email]> wrote:
Hi all,

A Hot Rod protocol change might be required as a result of [1].

In essence, the Hot Rod protocol does not specify how remote exec calls that return null should respond back to the client [2].

Returning an empty byte[] won't cut it since returning an empty String would be represented that way, and that's different to null.

I don't know how this could be handled without modifying the protocol, any ideas?

If modifying the protocol, adding a new status code would be a way to handle it.

Thoughts?

[1] https://issues.jboss.org/browse/ISPN-6406
[2] http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_hot_rod_protocol_2_0
--
Galder Zamarreño
Infinispan, Red Hat


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Remote execute null return (ISPN-6406)

Dennis Reed
A related question -- do you want to support null in the protocol?  Not
all languages even have a concept of null.

So you do need to make a decision whether to support null to the
exclusion of languages that don't have it (or make Hot Rod more
complicated to use in those languages), or disallow null to increase
interoperability but with a restriction of functionality in those
languages that do allow it.

-Dennis


On 04/20/2016 08:00 AM, Sebastian Laskawiec wrote:

> I think this is pretty common problem [3].
>
> On the other hand most of the users won't be interested in
> distinguishing nulls from empty strings (at least in my opinion). So how
> about leaving it as is by default and creating some configuration
> parameter for using new status code as you suggested (just in case
> someone would have to distinguish those two).
>
> This way we would be somewhat backwards compatible and we would have a
> rescue option for some users who would need this feature.
>
> [3] http://blog.bdoughan.com/2012/04/binding-to-json-xml-handling-null.html
>
> On Tue, Apr 19, 2016 at 6:31 PM, Galder Zamarreño <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi all,
>
>     A Hot Rod protocol change might be required as a result of [1].
>
>     In essence, the Hot Rod protocol does not specify how remote exec
>     calls that return null should respond back to the client [2].
>
>     Returning an empty byte[] won't cut it since returning an empty
>     String would be represented that way, and that's different to null.
>
>     I don't know how this could be handled without modifying the
>     protocol, any ideas?
>
>     If modifying the protocol, adding a new status code would be a way
>     to handle it.
>
>     Thoughts?
>
>     [1] https://issues.jboss.org/browse/ISPN-6406
>     [2]
>     http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_hot_rod_protocol_2_0
>     --
>     Galder Zamarreño
>     Infinispan, Red Hat
>
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Remote execute null return (ISPN-6406)

Galder Zamarreño
Thanks guys for the feedback.

We already implictly support null in some of the commands, e.g. get returns a particular status code when the key is not found.

Exec should have something like that eventually but for now the best would be to send back an empty byte[] when null is returned. That's better than what we do right now and as Sebastian rightly said, it should be not much different for the users.

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 20 Apr 2016, at 23:53, Dennis Reed <[hidden email]> wrote:
>
> A related question -- do you want to support null in the protocol?  Not
> all languages even have a concept of null.
>
> So you do need to make a decision whether to support null to the
> exclusion of languages that don't have it (or make Hot Rod more
> complicated to use in those languages), or disallow null to increase
> interoperability but with a restriction of functionality in those
> languages that do allow it.
>
> -Dennis
>
>
> On 04/20/2016 08:00 AM, Sebastian Laskawiec wrote:
>> I think this is pretty common problem [3].
>>
>> On the other hand most of the users won't be interested in
>> distinguishing nulls from empty strings (at least in my opinion). So how
>> about leaving it as is by default and creating some configuration
>> parameter for using new status code as you suggested (just in case
>> someone would have to distinguish those two).
>>
>> This way we would be somewhat backwards compatible and we would have a
>> rescue option for some users who would need this feature.
>>
>> [3] http://blog.bdoughan.com/2012/04/binding-to-json-xml-handling-null.html
>>
>> On Tue, Apr 19, 2016 at 6:31 PM, Galder Zamarreño <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>    Hi all,
>>
>>    A Hot Rod protocol change might be required as a result of [1].
>>
>>    In essence, the Hot Rod protocol does not specify how remote exec
>>    calls that return null should respond back to the client [2].
>>
>>    Returning an empty byte[] won't cut it since returning an empty
>>    String would be represented that way, and that's different to null.
>>
>>    I don't know how this could be handled without modifying the
>>    protocol, any ideas?
>>
>>    If modifying the protocol, adding a new status code would be a way
>>    to handle it.
>>
>>    Thoughts?
>>
>>    [1] https://issues.jboss.org/browse/ISPN-6406
>>    [2]
>>    http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_hot_rod_protocol_2_0
>>    --
>>    Galder Zamarreño
>>    Infinispan, Red Hat
>>
>>
>>    _______________________________________________
>>    infinispan-dev mailing list
>>    [hidden email] <mailto:[hidden email]>
>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev