[mapserver-dev] RFC 117 Question

[Stephen Woodbridge]

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