[mapserver-dev] RFC 117 Question

Stephen Woodbridge woodbri at swoodbridge.com
Thu Feb 2 12:39:11 PST 2017


Correction: Thomas not Even made the suggestion about keeping both 
versions of php mapscript around.

On 2/2/2017 3:07 PM, Stephen Woodbridge wrote:
> Hi Jeff, Daniel,
>
> Daniel, I think you are probably the most knowledgeable person of the
> subject of php mapscript. Weren't you involved with the origin
> implementation?
>
> Regardless, I have not personally used any flavor of mapscript in about
> 10+ yrs, so I'm not going to be much help. I raised the issue only
> because historically, I remember that the php mapscript API differed
> from the SWIG API. My presumption is that the PHP SWIG API will not be
> 100% compatible with the old PHP mapscript API.
>
> This is for a major release, so backwards compat can be broken. I
> strongly support moving forward with the PHP SWIG implementation. I do
> not expect all old php mapscript to work under the SWIG interfaces. I do
> not believe this should hold up the release, but others might disagree
> on that.
>
> I believe Even, suggested keeping the old php api also, but deprecating
> it and then removing it, but that sounds like a lot of additional work,
> but maybe it isn't.
>
> Regarding documenting the changes, do we have a php mapscript test
> suite? If so, this should break for each PHP SWIG incompatibility and
> documenting how those issues were fixed to work on the new API should
> give you all that you need. If we don't have a test suite, then that is
> another issue and maybe one should get built.
>
> Best regards,
>   -SteveW
>
> On 2/2/2017 2:04 PM, Jeff McKenna wrote:
>> Hi SteveW,
>>
>> As we had discussed during the PSC meeting and noted in the RFC, the
>> goal here is to move to a long-term supported method for supporting PHP
>> in MapServer.  The timing is good in that SWIG now fully supports PHP 7,
>> and, also the (unwritten) factor in Open communities: someone cares
>> enough to propose this to the MapServer PSC - willing to do initial
>> builds, testing, documentation (adding it to the migration guides, as
>> mentioned in RFC and your message), and managing contributions to the
>> code.
>>
>> It sounds like you are searching for more documented history, which is
>> fine, but at some point we must get moving: release, get feedback &
>> contributions, & improve.  From the number of devs offering their
>> support through the ticket, it sounds like many are waiting to get their
>> hands on some PHP7 support, and then add to it.  We already have several
>> mapscripts handled by SWIG, and they have each 'extended' their own
>> custom objects and methods (which will also come into our PHP SWIG over
>> time).
>>
>> We cannot guarantee that everyone's existing PHP applications will work
>> perfectly after an upgrade, but we can test, document the changes
>> needed, and call for contributions to improve the compatibility support.
>>
>> Regarding the next steps: I did wait until the code sprint, as you can
>> see, so, on Monday I'll bring this to a vote to the PSC through email,
>> and give a 4-business-day voting period (longer than the normal 2 days,
>> to accommodate the chaos of a code sprint).  There is nothing like a
>> vote on an RFC to get feedback.
>>
>> Thanks,
>>
>> -jeff
>>
>>
>>
>> On 2017-01-19 11:46 AM, Stephen Woodbridge wrote:
>>> Hi All,
>>>
>>> We discussed RFC 117: PHP 7 MapScript Support Through SWIG [1] and had a
>>> question.
>>>
>>> PHP mapscript has historically been a custom interface where the other
>>> mapscript flavors have been SWIG based. There was discussion in the past
>>> about converting PHP to use SWIG, but that didn't at the time move
>>> forward for some reason(s) like:
>>>
>>> * SWIG had issues with PHP?
>>> * moving to SWIG would break exisiting PHP mapscript applications
>>> * others?
>>>
>>> So my question is are these still issues?
>>>
>>> With the release 7.0 we can have breaking changes, but they should be
>>> documented in the migration guide if needed.
>>>
>>> Since I have not read and major discussion on this, my presumption is
>>> that this is no longer an issue.
>>>
>>> -Steve W
>>>
>>> [1] http://mapserver.org/development/rfc/ms-rfc-117.html
>>>
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-dev


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



More information about the mapserver-dev mailing list