Re: athena evolution path to 3G networks 'not so reliable' connections

This is a multi-part message in MIME format.
--------------000602020404010309070602
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

[email protected] wrote:
snip...
> exactly what the current state is on Windows, though.
For me everything is working just plain ok, I develop all my LivePage 
stuff (card games) with Eclipse on MSW and deploy to OpenBSD. During two 
years of operation and heavy development we didn't have a single hickup 
or problem in the last 12 months, which is definitely great.

Coming back to the original subject line of this thread our production 
runs with the attached patch for Athena/__init__.js now for quite some 
time and the user complaints about 'connection lost' dwindled to nothing.

With this patch installed, the browser no tries much harder to connect 
back to the server, meaning you can now even switch off wifi on the 
iPhone and hop over to 3G while you're LivePage is still alive, so 
Athena needs no evolution, it's already there.

BTW, the patch of course survives all the tests :-))

Mahalo, Werner

--------------000602020404010309070602
Content-Type: text/plain;
 name="__init__.js.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="__init__.js.patch"

559c559,562
<         if (!self.running || self._paused) {
---
>       function delayedFlushMessages() {
>         self.flushMessages();
>       }
>       if (!self.running || self._paused) {
594c597
<             if (self.failureCount < 3) {
---
>             if (self.failureCount < 7) {
596c599
<                     self.flushMessages();
---
>                   Divmod.Runtime.DelayedCall(self.failureCount * 1000, delayedFlushMessages);

--------------000602020404010309070602
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline