> 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
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 UUID
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/29/2014 05:27 PM, Aurelien Bompard wrote:
> Hi Florian!
>
> I think mailmanclient should not expose a different value as the
> REST API does (the fact that it's an int representation of a uuid
> isn't exactly obvious from the outside, so a non
> If the user_id value changes depending on whether
> you are using the API directly via HTTP or through mailmanclient, that
> might be hard to understand.
>
Ah, very good point. I'll do the conversion myself then I guess.
A.
___
Mailman-Developers mail
Hi Florian!
I think mailmanclient should not expose a different value as the REST
> API does (the fact that it's an int representation of a uuid isn't
> exactly obvious from the outside, so a non-explicit conversion could
> potentially lead to some confusion).
>
Hmm, to me the current situation i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Aurélien,
On 10/27/2014 04:36 PM, Aurelien Bompard wrote:
> Hey folks,
>
> Mailman stores user_ids as UUIDs in the database, and they are
> converted on the fly to integers by the REST API. However, the
> mailmanclient library do not convert them
On Sep 21, 2012, at 10:06 PM, Florian Fuchs wrote:
>P.S.: @Barry: Is there a way to get the "list_id" property from a list
>resource in the API? The JSON returned by /3.0/lists/ doesn't
>seem to contain such a field. So in order to make mailman.client work with
>3.0b2, I simply used fqdn_listname
