gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] Openstreetmaps works again + remoting dumps


From: strk
Subject: [Gnash-dev] Openstreetmaps works again + remoting dumps
Date: Sun, 14 Dec 2008 13:59:10 +0100

I've been working with Jason on fixing the potlatch editor
of OpenStreetmap. And.. SUCCESS :)

There were two problems:

        1) the lighthttpd running on osm doesn't accept Expect: 100-continue
           headers. That is, it won't accept a Continue, but won't either
           respond correctly. There's a bug item about it can't remember where.
           Anyway, libcurl sends an Expect: continue based on a different
           heuristic then the adobe player, thus doing it even when the adobe
           player wouldn't. I've tested that the adobe player DOES send Expect
           lines in other (bigger) calls. In any case the fix here was to
           instruct libcurl NOT to send those headers.

        2) For remoting (but not for SharedObject) Array objects that only
           have positive integers property names are encoded as STRICT_ARRAY.
           This is kind of crazy because if you set your empty array's length
           to a huge number you'd be generating a huge traffic (which you 
           wouldn't with ECMA_ARRAY encoding).
           Anyway, the osm ruby server side of things gets confused if it
           receives ECMA_ARRAY when it expects STRICT_ARRAY, so we fixed
           this too.

Now, for (2). While we have an automated test for SharedObject, which shows
there's no way to obtain a STRICT_ARRAY encoding, we don't have an automated
one for the remoting part. Jason drafted one, and we're discussing how
to make it available for general public and self-contained to verify with
the pp.

An similar test I've run locally, by simply sending NetConnection.call and
dumping the traffic, to check when we'd need a STRICT and when an ECMA.

Attached are 3 files:
        - remote.as: file you can compile with Ming to obtain a remote.swf
        - remote.pp: commented dump of traffic generated by adobe player
        - remote.gnash: commented dump of traffic generated by gnash trunk 
(after fix)

You may see that gnash still handles a few corner case in a bogus way.
The first is based on bogus handling of non-integer array property assignment,
the second on bogus handling of empty string property names.
Hopefully can both be tested with the actionscript.all framework, but of course
having a self-contained test (involving a server) would be great.

Have fun with map making !
 If I may suggest a starting point:
 http://www.openstreetmap.org/edit?lat=42.3075&lon=12.1628&zoom=14

--strk; 

 GIS & Flash consultant/developer     ()   ASCII Ribbon Campaign
 http://foo.keybit.net/~strk          /\   Keep it simple! 

Attachment: remoting.as
Description: Text document

Attachment: remoting.pp
Description: Text document

Attachment: remoting.gnash
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]