Changes between Version 7 and Version 8 of TorontoCodeSprint2009Notes


Ignore:
Timestamp:
Mar 7, 2009, 8:24:05 AM (15 years ago)
Author:
dmorissette
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TorontoCodeSprint2009Notes

    v7 v8  
    1919 * Thomas presented the approach of rendering plugins
    2020
     21= MapServer Toronto Code Sprint 2009 =
     22
     23== Agenda ==
     24
     25See http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009_Agenda#Mapserver
     26
     27== Minutes, Actions, Decisions ==
     28
     29=== 1. XML mapfiles ===
     30
     31 * A draft RFC is at http://mapserver.org/development/rfc/ms-rfc-51.html
     32 * There are concerns about the use of the CWXML library and the benefits of a binary encoded format
     33 * The need we are trying to address is the ability to build MapFile Editors that would be facilitated by the existence of a XML mapfile format (since the current mapfile format makes it impossible to write a forward-compatible parser)
     34 * There are concerns about having to support another set of parsing functions. Just keeping the existing mapfile.x read/write functions in sync is already a challenge, so adding another set of reader/writer functions for XML will just make this worse.
     35 * Conclusion: After discussion, it was decided that for the time being we should '''develop a XML schema and a XSLT to convert from XML to text mapfile'''. If the new XML format takes off then we may consider implementing support for it directly in MapServer in a future release. It is understood that the XSLT approach doesn't provide a way to convert from text mapfile to XML, but this is a limitation we can live with for now.
     36
     37=== 2. Graphical rendering ===
     38
     39 * Discussion of the approach of rendering plugins
     40 * Conclusions???
     41
     42=== 3. Attribute type handling (for WFS) ===
     43
     44 * Ticket: http://trac.osgeo.org/mapserver/ticket/462
     45 * An itemObj structure has already been added to mapprimitive.h. We agree that this is the way to go, the C code should be updated to use itemObj instead of the array of itemnames, etc.
     46 * A RFC would be required for this.
     47
     48=== 4. Metadata and processing directives abuse ===
     49
     50 * What can we do about this?
     51
    2152== Breakout Sections ==
    2253