> > > 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. _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
