[Gluster-devel] Usage of xdata to send anything on wire

[Jeff Darcy]

> > > There were concerns raised around this for the below reasons:
> > > 1. word-size and endianness
> > > 2. security issues
> > > 3. Backward compatibility issues i.e. old/new client and server
> > > combination.
> > 
> > Can you please elaborate on the above 3 points? A bit more verbose
> > explanation of what and how the above factors cause problems will 
> > help.
> 
> The "word-size and endianness" point relates to XDR not being able to
> parse the values in a dictionary.

I can't help but point out that XDR is part of the problem here.  Just 
about every serialization format since (and that's a long time) has
handled unions, optional values, dicts/maps, and so on better, while
still performing better as well.  I know we need XDR for NFS, but that 
doesn't mean we have to use it internally.  Maybe with a non-XDR-based
protocol we could have typed dict fields that get packed and unpacked
properly as they cross the network.  Unfortunately, that means we'd need 
to use the RPC-provided dict structure instead of our own, which is a 
*ton* of code to change.

Since this part of the code is likely to be stuck in the past forever,
our main option here is to upgrade the dict structure to include types
(which are already implicit in which call was used to set each value)
and upgrade our de/serialization code to handle a richer wire format.

> > > Solution 1:
> > > To get rid of sending xdata on wire, one of the solution could be
> > > to have protocol versioning in Gluster. With this we can modify
> > > xdr structures for each release and get rid of xdata. But this 
> > > will be huge work.
> 
> I am not a big fan of this.

Do you mean you're not a fan of using protocol versions *at all*, or not
a fan of transitioning current xdata users to use version-specific
fields?  I'm in favor of the first, but would rather avoid the second as
much as possible.

> > > Solution 2:
> > > - Change dict, to not be an opaque structure , but an array of
> > > data elements which is a union of (int, string etc.).
> 
> This is what I have been thinking about for a while too already.
> Anything that gets put in a dict should also set a 'type'. Probably
> default to 'string', but for anything else we need to make it possible
> for generated XDR functions to (de)serialize the values.

We seem to be converging on the idea that dict values should be typed,
but I still believe dicts should remain dicts (a.k.a. maps/hashes) and
not arrays.