Just an update: the prototype I worked on to add a 'datatype' metadata parameter to the script seems to be working, so I'll be sending a PR for inclusion in 8.2.
Cheers, -- Galder Zamarreño Infinispan, Red Hat > On 29 Feb 2016, at 19:46, Galder Zamarreño <gal...@redhat.com> wrote: > > Hi all, > > I had a chat earlier with Tristan and he pointed me to the metadata > information that can be passed in script header. > > Given that so far (until compatibility is supported), Javascript client only > supports String key/values, a very simple solution to this problem would be > to define a new metadata parameter, e.g. data-type, which can optionally > define the type of key, value, parameters and returned object. E.g. in the > javascript client case, I could just say: data-type=utf8 in the header of the > script, and that would provide enough hints for the server to do its job by > interpreting byte arrays dealt with in exec command as UTF-8 strings. > > This method is much more user friendly than having user plug a marshaller > since it only requires a small change in the header of the script, as opposed > to having to change server side configuration. I'm working on a prototype for > this with hopes to include in 8.2. > > Cheers, > -- > Galder Zamarreño > Infinispan, Red Hat > >> On 29 Feb 2016, at 14:35, Vittorio Rigamonti <vriga...@redhat.com> wrote: >> >> Hi All, Hi Galder >> >> JBasicMarshaller.h is not an intent to go further along the way to implement >> a c++ JBossMarshaller, it has the only goal to provide a working 'exec' >> operation. >> The c++ exec currently works only with integer and "small" string data >> types, user can easily extends the marshaller to other basic types. >> >> My current model of the exec use case is this one (maybe it's too simplistic >> so correct me if I'm wrong): a "user defined consumer" consumes data >> produced by a "user defined producer", so maybe it could worth to evaluate a >> solution where the framework provides a common standard for communication >> (stringified json? or JSObject for in memory 100% Java) and let the user >> handle it's own data. >> This is a proposal approach specific to the exec scope, I can't say if it >> can be extended as a general approach where marshalling is involved. >> >> Cheers, >> Vittorio >> >> >> >> >> ----- Original Message ----- >> From: "Galder Zamarreño" <gal...@redhat.com> >> To: "infinispan -Dev List" <infinispan-dev@lists.jboss.org> >> Sent: Monday, February 29, 2016 11:28:55 AM >> Subject: [infinispan-dev] HotRod exec operation tight coupling with JBoss >> Marshaller >> >> Hi all, >> >> While implement `exec` operation for the JS client, I've encountered an >> issue with how the exec parameters and return types are marshalled. >> >> The essence of the problem is that the server marshalls these objects >> instead of having the client drive how these are marshalled. As a result of >> this, for a JS or C++ client to be able to use `exec` with default >> configuration, they need to understand JBoss Marshaller format, which is not >> good. >> >> I'm not sure this would have been unavoidable due to the characteristics of >> `exec` but I wanted to see if we can find a good way to solve or get around >> this issue. Long term, we need better encoding handling both for incoming >> and returning types, but the question is whether we can find a way to better >> solve this until then. Here are some options: >> >> - For the C++ client, Vittorio has part implemented the JBoss Marshaller >> format [1], but I'm kinda reluctant to go down this path since that creates >> a lot of work for us as the number of types that can be discovered in a >> JBoss Marshaller format byte array are quite considerable [2]. We're bound >> to miss one of those and since clients could execute any script, the chances >> are high IMO... >> >> - An alternative would be for the JS/C++ clients to only support exec when >> the marshaller is one that enables compatibility mode. The idea here is that >> for compatibility mode to work, all clients involved are going to be set up >> with a marshaller that can work for all of them. Working on such marshaller >> is time better spent than on implementing the JBoss Marshaller format. We >> had a separate discussion on this topic in another dev thread... >> >> Any other ideas someone might have? >> >> Cheers, >> >> [1] >> https://github.com/infinispan/cpp-client/blob/master/include/infinispan/hotrod/JBasicMarshaller.h >> [2] >> https://github.com/jboss-remoting/jboss-marshalling/blob/master/river/src/main/java/org/jboss/marshalling/river/Protocol.java >> -- >> Galder Zamarreño >> Infinispan, Red Hat >> >> >> _______________________________________________ >> 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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
