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 <der...@redhat.com> 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 <gal...@redhat.com >> <mailto:gal...@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_protocol_2_0 >> -- >> Galder Zamarreño >> Infinispan, Red Hat >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
