RFC 16: MapScript WxS Services

Stephen Woodbridge woodbri at SWOODBRIDGE.COM
Fri May 19 00:00:10 EDT 2006

Frank Warmerdam wrote:
> Frank Warmerdam wrote:
>> Folks,
>> It turns out I'm very keen to get "committing" on RFC 16, so I would
>> like to promote my request for comments to a request for votes to 
>> proceed.
>> Given no vetos by the end of Tuesday afternoon I could get committing
>> Tuesday night.
> Folks,
> On a review of the RFC 16 email in my folder, I don't see any +1's.  So
> even taken my own as implicit it appears the RFC has failed to pass.
> Should I take this as a lack of support for the proposal?  Before the
> formal call for votes it seemed to have general support.
> I have tried to address Tamas's concerns about multi-threading and
> the msIO code, basically by claiming that I'm just using the existing
> mechanism and not making things any worse for multi-threading.  I tried
> to respond to some of SteveW's suggestion regarding msIO filters by
> basically claiming this would be hard to expose properly in mapscript.
> If our chairman has no problem with it, I will leave the vote on RFC 16
> open till the end of day tomorrow for votes.
> I'll state my vote now as +1 for my own proposal as it stands.
> PS. I will hold off on re-issuing RFC 17 (dynamic arrays) till after I
> get the RFC 16 work done.  I don't want to confuse things too much.
> Best regards,


Sorry, I was waiting for the discussion to come to some conclusion and I 
missed the fact that it just got quiet.

I do not think I have any major objections that would vote against your 
proposal, but I do think Tamas made a bunch of good points and he 
volunteered to help pursue the direction that he was advocating. I think 
his offer needs to be considered especially if Tamas can provide 
assistance as offered and it does not exceptionally delay your proposals 

So I'll vote +0 (neutral but ok to proceed) on your proposal as is. I 
think it would be a big win if you and Tamas could collaborate on this 
in some way, but if I recall correctly you already have your proposal 
roughly implemented and ready to check in if approved, so a delay might 
be painful.


If Frank moves forward with this, does it make the work you are doing on 
threading significantly harder to do?

Clearly if we are moving mapserver to a more thread neutral 
implementation then all current?/future development needs to be 
implemented along the evolving thread neutral standards (whatever they 
might be). Someone should probably take a stab at writing up what these 
are as an rfc for approval - Tamas?

Best regards,
   -Steve W.

More information about the mapserver-dev mailing list