Python vs. IronPython : Round 2

Yesterday I let IronPython battle it out with TileCache, which was written for CPython and CGI.  IronPython was stumbling — not seeming like a drop-in replacement for CPython yet — but I didn’t quite call the fight.  I wanted to port TileCache’s CGI library calls to ASP.NET calls and see what I came up with.

After trivially porting TileCache’s CGI code, I discovered a new issue.  IronPython’s lacks support for ”os.access.”.  TileCache requires “os.access”.  I’m not sure where this method normally lives.  Its not defined in the “os” module of the Standard Library, but it works from CPython.  AFAIK, its magic. 

 With a bit more research, and I stumbled upon FePy.  “The FePy project aims to provide enhancements and add-ons for IronPython, an implementation of Python programming language.”  They’ve already addressed my “hashlib” problem, providing a custom .NET module for it and for “socket.”  They’ve also identified and patched 3 issues in IronPython, and 6 issues in the Python Standard Library when used with IronPython. 

FePy’s patches should fix my issue.  They’ve added “os.access” directly into the IronPython DLL.  However, FePy lists their patched IronPython DLL version as 1.1, while ASP.NET Futures seems to use a Version 2.0.  The thought ”with a little more effort, I can make this work” was beginning to feel familiar.  I’ll wait till FePy moves to 2.0.

Winners:  the FePy developers, notably Seo Sanghyeon, for relentlessly discovering and fixing IronPython bugs before MS can

Losers:  IronPython, for stumbling twice on a mere 44k of code (+400k of relevant, standard libraries)

Python vs. IronPython : TileCache

“There is a maker’s serial number 9906947-XB71. Interesting. Not fish. Snake scale.”  Blade Runner has shown how tell a real snake from a replicant snake:  (Sys.Version).  Beyond the superficial, what happens when we take the animoid IronPython , and attempt to replace CPython in a real-world battlefield?  I chose MetaCarta’s TileCache.

For those who don’t know, IronPython is MS’s implementation of Python on top of .NET.  Its pre-release software in the context of running it from ASP.NET, and therefore against the pre-release license to benchmark.  I won’t be doing that; nor do I need to.  The purpose is to see if IronPython is a drop-in replacement for CPython.  To be fair, I know next to nothing about Python in either implementation.

It took me less than 30 minutes to set up TileCache using CPython and CGI on MS’s IIS.  The directions weren’t 100%, but anybody with a clue can fill in the blanks.  Hint:  IIS has no default CGI handler. 

IronPython right now is much trickier.  I put about two hours into it, and didn’t get TileCache running in that time.  I did finally get everything to compile, but it took some work.  The basic problem is that IronPython won’t import compiled C/C++ modules.  The IronPython developers are aware of this, and will supposedly replace these compiled modules with .NET equivalents as time permits. 

For now, IronPython doesn’t ship with standard library equivalents, and must reference CPython’s modules, many of which in turn reference compiled C/C++ modules.  TileCache references script modules that reference the “hashlib” compiled module, even though I’m pretty sure that TileCache doesn’t use these. 

After a long, uneducated process to track down where “hashlib” was being imported, it was easy to comment out.  After this, TileCache would run, but it didn’t do anything.  I was just getting back zero-byte responses, because TileCache’s CGI-specific code needs porting to the ASP.Net environment.  To a .NET developer, the nice part is that VisualStudio’s debugging tools made it simple to track down this problem. 

Winners:  CPython, because it already works just fine

Losers:  Impatient developers?  People who waste time evaluating beta products?

JSON vs. Flash for Distributed Mapping

A few years ago I wrote a “Flash connector” for the ArcIMS HTML Viewer.  This “connector” took advantage of Flash’s security sandbox model, which allows cross-domain data connections under special, protected circumstances.  The point was to allow ArcIMS to get around JavaScript’s “same-domain policy” limitation — to allow distributed web-map calls without a proxy. 

Really the point was to put an ArcIMS HTML viewer on my HTML-only web-resume host, but I digress.

 In the browser, ArcIMS’s JavaScript and Flash communicated via Flash’s “External Interface” methods.  ArcIMS could post ArcXML to and from other domains.  Flash’s security model requires a “crossdomain.xml” be published on the remote-domain.  Jan Bliki’s excellent Flash + ArcIMS work at the EEA offered both the ArcIMS backend and “crossdomain.xml” to test all of this against.

The whole point, again, was to get around JavaScript’s ”same-domain policy” limitation.  Fast forward to 2007 where JSON is commonplace.  One accepted JSON paradigm is On-Demand Javascript – a special case where JSON-encoded data may be accessed across domain boundaries.  Essentially, an HTML <script> tag may be dynamically generated in the DOM, thus loading the JSON data.  There is some debate whether this is a feature, or a bug. 

For a moment, I considered rewriting my “Flash connector” as a “JSON connector”.  However, the lack of domain restrictions on DOM-based JSON requests does not apply to XmlHttpRequest JSON requests.  This means that JSON data may only be loaded via an HTTP “GET”; you can “POST” information to remote domains.  Hence, Javascript still cannot POST data to remote domains.

Overall?  If you’re not interested in proxying, 2-3 year old Flash technology is still better than JavaScript.  Why?  The security model.  Microsoft has been hinting at giving Silverlight a permissive cross-domain policy.  I suggest they do so.

Let me know in the comments if there is any interest in me posting a “Flash-connector” walk-through.

Best GIS Infrastructure?

If you could take any existing GIS products, and not have to worry about personnel / training / cost / platform considerations, what you would be your ideal GIS infrastructure?

 I think was thinking I’d like Oracle Spatial + ArcInfo + GeoNetworks + Mapserver +  MetaCarta’s TileCache + Openlayers.

Its funny – I rarely/never use these components.  Perhaps I chose them because I don’t know their faults.