[Mailman-Developers] mailman.client and UUIDs for user.user_id

[Barry Warsaw]

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