librelist archives

geonode on jython?

From:

Chris Holmes

Date:

2010-10-21 @ 05:15

Anyone know of any major blockers that would prevent GeoNode from being 
run on jython?  It looks like django can run on jython.  But if there 
are C libraries that we rely on then that would slow things down. 
Though we could make them use a java equivalent.

There's a potential GeoNode project where the client only allows running 
java.  So it'd be quite nice if we could run in jython.

I think thenfollowing areas would have to be taken care of:


1. Compatibility with Python 2.5
2. Remove the PIL dependency
3. Because of 3, tweak the avatar app to only use gravatar or build a
compatible one in java.
4. Remove the Reportlab dependency (btw, I have no idea what breaks if
we do that, I would have thought reportlab would power the printing
module but we have a geoserver/mapfish extension for that)
5. Compatibility with Django 1.1

Those are the ones from the top of my head.

Ariel

Sent from my iPad

On Oct 21, 2010, at 0:16, Chris Holmes <cholmes@opengeo.org> wrote:

> Anyone know of any major blockers that would prevent GeoNode from being
> run on jython?  It looks like django can run on jython.  But if there
> are C libraries that we rely on then that would slow things down.
> Though we could make them use a java equivalent.
>
> There's a potential GeoNode project where the client only allows running
> java.  So it'd be quite nice if we could run in jython.

We currently have three native-code dependencies:

   - GDAL - used to convert bboxes from lat/lon to map coordinates.
    Currently the only destination projection is web mercator, but I think as
   specialized applications of GeoNode ramp up we will probably want other
   options.
      - we could fake our current usage by replacing it with a simple
      function, translated from OpenLayers or another library that
supports just
      this operation.  My initial cut of the bbox rewriting did exactly this,
      fwiw.
      - we could arrange things so that all translation happens on the JS
      and GeoServer side, where we have proj4js and gt-referencing as
      alternatives.  I would like to avoid having this constraint on
the GeoNode
      design though.
      - we could create a jython alternative to the gdal python bindings
      which is API-compatible for our purposes, probably a wrapper around
      gt-referencing
   - reportlab (pdf generator) - I don't think we actually use this any
   more; the dependency was added for a reporting tool which was later
   scrapped.
   - PIL (image manipulation) - To get away from this dependency, we'd have
   to rewrite the avatar library, or again provide a jython alternative to PIL
   which is API-compatible.

I am also not sure what the story is for running django-admin commands
against a Django application deployed as a webapp.  We would likely need a
way to run updatelayers from the administration console.  Finally, the
django-jython toolset currently only supports Django 1.1.1 and we are
already using features from Django 1.2 to support per-layer permissions.

So, it's doable, but more than an afternoon's work to get set up.

--
David Winslow
OpenGeo - http://opengeo.org/

On Thu, Oct 21, 2010 at 1:15 AM, Chris Holmes <cholmes@opengeo.org> wrote:

> Anyone know of any major blockers that would prevent GeoNode from being
> run on jython?  It looks like django can run on jython.  But if there
> are C libraries that we rely on then that would slow things down.
> Though we could make them use a java equivalent.
>
> There's a potential GeoNode project where the client only allows running
> java.  So it'd be quite nice if we could run in jython.
>