* Phil Mayers <p.mayers@imperial.ac.uk> [2006-07-31 15:57:46 +0100]:
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.
You could make XHR calls via this reverse-proxy using the Athena primitives for XHR, though.
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.
I don't see any reason why Athena has to replace MochiKit. For the most part, the two libraries are completely orthogonal. If you want to use MochiKit's JSON-RPC functionality, nothing is stopping you.
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.
MochiKit does not implement any kind of peristent HTTP transport, so this seems a moot point.
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.
I'm not personally concerned with this use case, so I'm not likely to spend any time on implementing this. I would imagine that patches to refactor Athena's Widget code to be less dependent on the Athena client-server transport would be accepted, though, so others are free to do the work to implement this.
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 point is that nothing is stopping you from doing this, so far as I can see.
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?
There are no "fixes". The copy of MochiKit distributed in Nevow is completely unmodified so far as I am aware (even if it isn't the latest version). There is Athena-specific functionality, not implemented at all by MochiKit, that requires either certain browser functionality, or browser-runtime-specific code. For example, the Divmod.Class system results in widespread idiomatic usage of named function expressions. Safari's JavaScript parser chokes on this as invalid syntax, hence the lack of Safari support. As was pointed out elsewhere, this problem has been fixed in WebKit upstream, so will presumably make its way into Safari at some point; when this happens, doing the rest of the work to support Safari should not be very difficult. This is basically all completely orthogonal functionality, however; Athena is not reimplementing large portions of MochiKit verbatim, it is implementing different functionality in different ways, with a few exceptions such as XHR and Deferred. Once the MochiKit dependency in Athena is completely gone, there will be no need to distribute MK alongside Athena, and thus developers will be free to include whatever version of MochiKit they wish for their own use, without having to jump through hoops. -- mithrandi, i Ainil en-Balandor, a faer Ambar