
Tristan Seligmann wrote:
* Valentino Volonghi aka Dialtone <dialtone@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?