[Mapserver-users] Mapscript: Perl v PHP

[Dimeo, Christopher]

"Bzzzt, wrong. :)

The PHP MapScript module has a host of developers, a legion of users, and is
the basis for several higher-level products like MapLab and Chameleon"

Thx for the reply.

This is encouraging.  I am most comfortable with PHP.

c


-----Original Message-----
From: Sean Gillies [mailto:sgillies at frii.com] 
Sent: Wednesday, April 28, 2004 10:54 AM
To: Dimeo, Christopher
Cc: 'mapserver-users at lists.gis.umn.edu'
Subject: Re: [Mapserver-users] Mapscript: Perl v PHP


Dimeo, Christopher wrote:

> Hi all-
> 
> I was just looking through the functionality lists for mapscript, both 
> PHP and Perl.  Presently, it appears that Perl is the more robust of 
> the two.
> 
> Is this the case?  If no:
> 
> What are the strengths of one versus the other?
> Aside from language preference why would/should I use one versus the 
> other?
> 
> If yes:
> 
> Is the intent to provide equal functionality in both versions (within 
> constraints of each respective language)?
> 
> Thanks
> c
> 

Bzzzt, wrong. :)

The PHP MapScript module has a host of developers, a legion of users, and is
the basis for several higher-level products like MapLab and Chameleon.  It
works on UNIX, Linux, Win32.  It is certainly more mature and robust than
the Perl MapScript module, which doesn't work yet (to my 
knowledge) on Win32.

The Perl MapScript module is one language interface to code that it shares
with Python, Ruby, and (defunct?) Java MapScript modules through the use of
SWIG, the Simple Wrapper Interface Generator, www.swig.org. Recent
development of this module, and testing of the module is primarily driven by
Python users.

If you are not already tied to a language, take a look at Python.  After
PHP, it is the most feature-rich MapScript module, and you may also be able
to use the GDAL/OGR modules (Python only as far as I know).  The main
weakness of Python is that it is a bit slow but since MapScript is C code
and GDAL/OGR is C/C++ you are spared from this.

The answer to your final question is yes, we are trying to merge the PHP and
SWIG-based (Perl, Python, Ruby) modules to a common API.  We're already
85-90% there by my conservative estimate.

cheers,
Sean