[mapserver-commits] r10752 - trunk/docs/en/development/rfc

[svn at osgeo.org]

Author: sdlime
Date: 2010-11-21 21:58:24 -0800 (Sun, 21 Nov 2010)
New Revision: 10752

Modified:
   trunk/docs/en/development/rfc/ms-rfc-64.txt
Log:
A few minor updates.

Modified: trunk/docs/en/development/rfc/ms-rfc-64.txt
===================================================================
--- trunk/docs/en/development/rfc/ms-rfc-64.txt	2010-11-22 05:51:59 UTC (rev 10751)
+++ trunk/docs/en/development/rfc/ms-rfc-64.txt	2010-11-22 05:58:24 UTC (rev 10752)
@@ -52,7 +52,7 @@
 I propose moving to a setup where a logical expression is tokenized once (via our Flex-generated lexer) and then Bison/Yacc parser 
 works through tokens (via a custom version of yylex() defined in mapparser.y) as necessary for each feature. This eliminates the
 substitution and tokenize steps currently necessary and opens up possibilities for supporting more complex objects in expressions. 
-Basically we'd hang a list/array of tokens off an expressionObj, populate it in msLayerWhichItems() and leverage the tokens as needed 
+Basically we'd hang a list of tokens off an expressionObj, populate it in msLayerWhichItems() and leverage the tokens as needed 
 in the parser. The following new structs and enums are added to mapserver.h:
 
 ::
@@ -242,14 +242,14 @@
   2) All OGC filter operations need to be supported. Bounding box filters in particular have not been looked at.
   3) Need ''LIKE'' operator code. (e.g. Dr. Dobbs, 9/08, ''Matching Wildcards: An Algorithm'', pp. 37-39)
   4) How to handle layer tolerances in msQueryByFilter()?
-  5) Best way to manage tokens, array, list, tree? Bison/Yacc needs array or list, but both Frank and Paul have referred to trees.
+  5) Best way to manage tokens: array, list, tree? Bison/Yacc needs array or list, but both Frank and Paul have referred to trees. (Update: the tokens are now managed as a linked list.)
   6) Thread safety...
   7) Parser error handling, any errors have basically always been silently ignored.
 
 Bug ID
 ------------------------------------------------------------------------------
 
- Not assigned.
+ #3613
 
 Voting history
 ------------------------------------------------------------------------------