[mapserver-dev] RFC 64 - Call for a vote...

[Lime, Steve D (DNR)]

1) Thread safety. At the moment I use thread locks as we always have. So there's no regression there. I'd like to try and make things thread safe (at least for parser, as opposed to flex for mapfiles) for 6.0.

2) I would like to push the IN operator optimization off (unless someone is motivated now). I don't think it's trivial exercise since we need to support both string and numeric lists on the right-hand side.

Steve

-----Original Message-----
From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Stephen Woodbridge
Sent: Monday, November 22, 2010 11:19 AM
To: mapserver-dev at lists.osgeo.org
Subject: Re: [mapserver-dev] RFC 64 - Call for a vote...

On 11/22/2010 11:39 AM, Lime, Steve D (DNR) wrote:
> Need to act on RFC 64 one way or another so I'll call for a vote.
>
> http://mapserver.org/development/rfc/ms-rfc-64.html

Steve,

What are you thoughts on the TODO list? Are these getting pushed out 
post 6.0?

Are you planning to put thread locks around the parser global usage so 
you don not break thread safety? As opposed to making the code thread 
safe now? I do not think you can regress thread-safety and break that.

For the IN optimization, if the IN list is large, load the tokens into a 
btree structure and search will be very fast. I believe this is how 
postgres does it internally.

Unless there are some serious concerns from others on issues I'm not 
seeing, this seems like a huge amount of value for relatively low risk, 
other than changing a lot of code. I think this needs to go into 6.0.

+1 for 6.0

-Steve W
_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev