Hot Rod's 'execute' operation is tightly coupled with JBoss Marshalling making it difficult to run an execute operation from Javascript, who currently supports plain, UTF-8 String keys and values.

The essence of the problem is that the server marshalls parameters and return values 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.

IOW, if a JS client sends a UTF-8 string as parameter, server tries to unmarshall it using the JBoss Marshaller and it fails. This happens because exec assumes the client is a Java client. The same happens with the return value.

On top of that, the script run from Javascript would be expect cached values to be Strings.

In order to accommodate the JS client's needs to support plain UTF-8 Strings, and also help C/C++ client, it was decided to add a new metadata parameter to the script called `datatype` which for JS scripts, it would take as value `utf8`.

When `datatype=utf8`, the following will happen:

1. Parameters to the script will be assumed to be UTF-8 Strings.
2. Cached values would be assumed to be Strings.
3. The return type of the script will be transformed into byte[] encoded as UTF-8 String.

When `datatype=utf8` is defined, no attempt to interoperate with data stored using a Java Hot Rod client or a REST client. To get such interoperability, compatibility mode would need to be enabled and both Java HR client and JS/C++ client would need to share the same marshaller. This is not yet in place but will come.