[Twisted-web] [Nevow] JavaScript code

[Tristan Seligmann]

* Phil Mayers <p.mayers at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://twistedmatrix.com/pipermail/twisted-web/attachments/20060731/a903afa0/attachment.pgp