[Twisted-web] [Nevow] JavaScript code

Phil Mayers p.mayers at imperial.ac.uk
Mon Jul 31 09:57:46 CDT 2006


Tristan Seligmann wrote:
> * Valentino Volonghi aka Dialtone <dialtone at divmod.com> [2006-07-29 22:48:09 +0200]:
> 
>>> If you want to use MochiKit in your own code, there's not too much
>>> stopping you; currently, it is problematic to try and use a different
>>> version of MochiKit to the one distributed with Nevow, but once this
>>> dependency is completely phased out, that problem will no longer exist.
>> Of course. I might use dojo toolkit as well. But having two different 
>> deferreds implementations in the same code is quite difficult to deal with. 
> 
> Is there anything besides XMLHTTPRequest that you would use MochiKit's
> deferreds for? If you're using Athena, you don't have any need for
> MochiKit's XHR support, so this seems to be a non-issue...

I can think of several reasons one might want MochiKit.

Due to the security model protecting XMLHTTP requests, you can only make 
requests back to the same origin server. Therefore, if you want to call 
an external (non-Twisted, non-Nevow, non-Athena) application from your 
Athena page, you might choose to glue that application into your server 
URL space using server-side reverse proxying.

If Athena is to replace MochiKit, it would need to provide at least as 
good primitives for e.g. JSON-RPC. If it does not, you'd still need a 
library to do so.

In *addition*, my understanding was that many (most?) browsers limited 
the number of outstanding HTTP requests you may have to a given server 
to 2. Therefore, running >2 "event loops" for XMLHTTP requests to e.g. 
different application spaces is impossible. If you happen to have 3 
application spaces deployed into your URL hierarchy, well, tough.

It is an unfortunate choice for some of us.

Finally, I think it's worth pointing out that one might want to use the 
Nevow+Athena code for widgetry and so forth, but if one already had an 
application API as e.g. JSON-RPC calls, exposing those calls *again* to 
an "implementation is internal detail" Athena channel is at best time 
consuming boilerplate, and at worst bug-riddled and insecure.

Athena-JS is more like a domain-specific language IHMO. It's not 
unreasonable to want to code the non-athena specific bits to a more 
general JS platform/framework/library.

My 2pence

> 
>> And also using mochikit would only solve the visual effects problem, 
>> whereas the browser compatibility problem won't be solved (not that I 
>> especially care about the bugged safari).
> 
> Increasing the usage of MochiKit in Athena would not solve the browser
> compatibility problem either: the lack of support for various browsers
> stems from functionality that is not implemented in MochiKit at all.

It seems a peculiar choice to not just fold those fixes back into 
MochiKit. The upstream developer(s) have good reputations for being 
sensible people, do they not?



More information about the Twisted-web mailing list