On 07:08 am, [EMAIL PROTECTED] wrote:
Hello Harald
Try the following before you proceed:
Run the nevow examples, go to calculator with IE7 or greater, then hit
F5 for reload in rapid sequence. You will hit the point where the
browser sits there seemingly deactivated with a waiting cursor. Wait
for the time it takes for the socket to come out of its TIME_WAIT state
and see the browser window come alive again.
You can provoke this behavior also by providing a sequence of
LivePages, going from one LivePage to the other.
The Athena implementation which was rewritten at SVN version 13786 to
This doesn't look like a rewrite of Athena:
http://divmod.org/trac/changeset/13786
I think you meant SVN version 14017?
http://divmod.org/trac/changeset/14017
Or maybe something else?
implement a better disconnect logic collides in my experience with the
limited connections IE's developer decided to use. At any particular
time the browser accepts only two open sockets (...)
This is in my opinion a fundamental flaw in the current Athena
implementation and leads to problems no end, because users WILL simply
NOT behave and will do the impossible. User feedback in our case was
so, that I was forced to live with the 'old' Athena stuff.
I don't think the flaw is in any way "fundamental". The whole design of
Athena is based around the idea that all the pieces are pluggable and
can be substituted. For example, ReliableMessageDelivery is a separate
class specifically so that it can be modified in isolation and we can
change this strategy without touching the rest of athena.
If you or anybody else sees a solution to that IE/TIME_WAIT problem I
would be more than happy to invest time into furthering Athenas
evolution, I like the concepts underneath and if they're coupled with a
decent JScript library the 'real app in the browser' becomes a reality.
Several things come to mind.
One is that you could simply submit a patch to ReliableMessageDelivery
to make it better. There are a number of obvious flaws with the current
implementation and it would be nice if it could be fixed. This is not a
very specific idea because browsers are awful, and I don't know of any
collection of pure-Javascript gross kludges to work around their
awfulness better than the current collection of gross kludges.
Another is that we could abuse a browser extension that supports real
sockets - say, Flash - to provide a better "default" experience, but
fall back to the current crummy behavior for the few users that don't
have it. A long time ago we did this, and there was a flash movie
called 'flashconduit' included with Nevow's predecessor (Woven). At the
time this was impossible to build and test either in an automated way or
on an open-source platform, so we abandoned that strategy.
Recently I've been playing with Flex, which is (among other things) a
toolkit for building Flash movies out of actual source code rather than
the atrocity that is a .FLA file. It's also amenable to automated
builds and testing, which FLA files had impeded in the past.
Java is another option, and although the typically long startup time for
applets wouldn't make it ideal, it might be a reasonable backup option.
I hear .NET has something called "no touch deployment", and Firefox has
a socket API for extensions which an extension could selectively expose
to the web page context.
Anyway, all of these options are really just different ways that the RDM
might be adjusted; all of them could be implemented and the best option
selected automatically based on the user's browser. Given that you seem
to have some specific requirements based on specific user experiences, I
hope that you'll contribute patches that we can discuss and test in a
variety of different browser situations.
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
