[Twisted-web] Athena callRemote with str()

[Jean-Paul Calderone]

On Sun, 02 Jul 2006 00:01:49 +0100, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
>Jean-Paul Calderone wrote:
>>On Sat, 01 Jul 2006 22:12:19 +0100, Phil Mayers <p.mayers at imperial.ac.uk> 
>>wrote:
>>>Is the behaviour that Athena won't permit a server-side callRemote to 
>>>return a str() and mandates a unicode() intentional? If so, what is the 
>>>rationale?
>>
>>Yep.  JavaScript doesn't have a byte string type, only a character string
>>type.  Athena won't guess what kind of characters you want to result from
>>a Python str.
>
>Hmm. I had not appreciated the wholly character-based nature of javascript 
>strings. Thanks - I'll recast str() as unicode(). In case anyone is 
>interested the specific thing I was passing was packed MAC and IP addresses, 
>which of course are not unicode strings, for a host management database. I 
>will have to unpack them to get unambiguous encodings :o(
>
>On a related note, is there any particular reason that Nevow uses it's own 
>json lib instead of $thebetter of the python json libs? Because at least one 
>of them has support for pluggable mappings of types to serialisers - e.g. 
>DateTime -> $thestringrep - allowing applications to be explicit and hook 
>when sending complex types over the wire, but without having to do so in 
>boilerplate each call.

The historical explanation is that nevow's was written before most of the
others (the ones which predate it were unusably bad at the time).

The rest of the explanation is that JSON is not actually part of the
public API provided by Athena.  It's an implementation detail which may
well go away at some future point.  Specifically, I am currently
contemplating using a packed format for client -> server communication.
There aren't plans to replace JSON in server -> client messages yet, but
it could happen at some future point.

Jean-Paul