Better token in the future?

[Jeff]

Although simple to understand and manage, I don't think the integer
token is robust enough for production use by a 3rd party (non-python)
client. The token could eventually overrun the max integer bounds
imposed by other languages after a large number of requests. So, in
my case, using XMLRPC from Java some day we'll hit that magic number.

Perhaps the token could recycle modulo some number? Or some other job
persistence could be implemented? Perhaps even something as long as a
session key, 128-bits, etc?

[Daniel]

I could put in a some code to recycle at around 2^31. At the moment,
the token isn't persistent server restarts, and was really meant as a
quick way to disambiguate. I should probably review the code for
other constructs that may become unwieldy after 2 billion jobs.

You're right though. For persistent disambiguation, the token could
be a md5 of the script + submission date.

Another way is just to return the number as a string. This is
probably the simplest way. The client need not care about what it is,
other than an opaque string that can be used to retrieve job/session
state. I'm in favor of this route, since it allows the implementation
to change without breaking anything in the client.

-Daniel