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

On Oct 29, 2014, at 05:27 PM, Aurelien Bompard wrote:
It's really the same value, just a different representation of it. The conversion UUIDs to integers is completely reversible.
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

So Aurelien and Florian, what do you think? Should we use the hex representation of the UUID and should I keep backward compatibility.
If we can't see any valid reason for converting to ints today, I would personally vote for not converting in the REST API, and for mailman.client to return the UUID object (not the hex string), because I think a python client library should expose python idoms and objects when possible. If we do that, keeping backwards compatibility could be useful indeed, and you can start from my change here: http://bazaar.launchpad.net/~abompard/mailman.client/uuids/revision/58
But FYI, I have already adapted my code in HyperKitty to do the conversion to UUIDs, so I really don't mind if we keep the status quo. Let's just do what's best in the long run.
A.

So Aurelien and Florian, what do you think? Should we use the hex representation of the UUID and should I keep backward compatibility.
If we can't see any valid reason for converting to ints today, I would personally vote for not converting in the REST API, and for mailman.client to return the UUID object (not the hex string), because I think a python client library should expose python idoms and objects when possible. If we do that, keeping backwards compatibility could be useful indeed, and you can start from my change here: http://bazaar.launchpad.net/~abompard/mailman.client/uuids/revision/58
But FYI, I have already adapted my code in HyperKitty to do the conversion to UUIDs, so I really don't mind if we keep the status quo. Let's just do what's best in the long run.
A.
participants (2)
-
Aurelien Bompard
-
Barry Warsaw