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 <galder(a)redhat.com
<mailto:galder@redhat.com>> 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_prot...
--
Galder ZamarreƱo
Infinispan, Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev