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?

MapWrecker 2.0: Change vs. Progress

In the spirit of new releases, I hereby rechristen this site MapWrecker 2.0

There will even be a new theme:  battles!  Every title will have a “vs” in it.  Every post will be a fight-tastic feature comparison of GIS thingamabobs.  MapWrecker 2.0 will offer streamlined workflows (I’ll declare winners and losers at the end) and increased cohesion for greater niche market capatialization (I don’t know what this means).

Winner: Change! 

Losers: Progress?

GeoCommons: James vs. Steve

Steve’s Little World and Spatially Adjusted are having a tiff over the usefullness of the GeoCommons services.

Need I remind you that “destruction” is one of the sub-topics of this blog?  Like a moth to a flame!!  I must weigh-in!  I’ve recently decided I’m old-school GIS, not one of those NeoGeography leotard-wearing types.  But tasteless sarcasm takes no prisoners — let the quips begin!

 

First of all, let me remind everyone of Executive Order 12906.  It has this little line “each agency shall document all new geospatial data it collects or produces, either directly or indirectly, using the standard under development by the FGDC.”  I’m a true American; I love my country, and hate my government.  If they say use FGDC metadata, I say metadata is for sissies pansies.

Bush needs to make that vital decision to privatize the FGDC, and throw the no-bid-contract at Google or FortisOne (who made GeoCommons).  We need more entrepenuers like FortisOne “applying its deep expertise in geographic analysis and visualization to the needs of clients such as the Department of Homeland Security.”  After all, Homeland Security isn’t a bunch of sissies… Name, Tags, and Descriptiton (GeoCommons’s fields) are metadata enough for those tough guys.

And besides, doing things right and following the rules is more than dull, its hard!  ESRI can barely do it, and we all love ESRI more than God.  Hell, OGC wrote the interoperability standard for cataloging and searching metadata (and by implication, data).  [There ain't no money in standards.]  Yeah, and OGC wrote it.  That means it’s a painfully long, stupid document–not worth reading.  So not only is the metadata schema completely ignored, but the cataloging protocol is too!

These specs are ignored because nobody really cares about details like spatial projections when we all know that Google only lets us use one.  And Google is clearly right, because they’re really popular and have a ton of money.  They don’t play by the rules, they are the rules.  I love them.  They’re getting the job done. 

And OGC?  Can’t we just privatize them too?

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.