On Oct 29, 2014, at 05:27 PM, Aurelien Bompard wrote:

Hmm, to me the current situation is more confusing, since the user_id property I get from the REST API is different from the one I find in the database.

It's really the same value, just a different representation of it. The conversion UUIDs to integers is completely reversible.

I guess it depends on the reason the UUID is serialized. If it's to avoid being messed up during the transport, it's a transport issue and I think the library should convert it back (but the original ascii string should not be a problem so it's probably not that. Anyone remembers why the REST API exposes the int value instead of the string? It happened in commit 7043 but the reason is not given in the commit message.

I don't remember exactly why I changed it to the int representation, but it could have been some limitation (valid or not) on restish. The log message doesn't describe that because IIRC, the REST API change happened at the same time that internally user ids were changed to UUIDs. So I probably tried a few things and settled on ints before I committed that change.

I could have been trying to optimize the wire format, given that UUID.int is 16 bytes whereas UUID.hex is 32 bytes.

Or maybe I was just being dumb. (Not mutually exclusive with the above. ;)

We could certainly change the JSON for a user to return the string (specifically, UUID().hex) but we'd need to return both for backward compatibility, if we care about that. Maybe we don't if we're just promising for now that mailmanclient is the level of API guarantee, and we make both changes at the same time.

I can probably figure out how to accept either ints or hex strings as input for identifying the user, but it might be tricky.

So Aurelien and Florian, what do you think? Should we use the hex representation of the UUID and should I keep backward compatibility.

Cheers, -Barry