MS RFC 70:MapServer项目中Tinyows的集成¶
- 日期
2011／04／14
- 作者
Olivier Courtin
- 联系方式
olivier dot courtin at oslandia.com
- 状态
采用
- 版本
MapServer 6.2
描述：此RFC建议在MapServer保护伞下进行Tinyows集成。
1。概述¶
Tinyows通常与MapServer结合使用，以提供WFS-T功能。
这里的想法是通过两个应用程序的单个 Mapfile 配置文件为最终用户提供一个更集成的解决方案。
并将Tinyows放在MapServer项目的保护伞下，再次增加其使用量。
2。建议的解决方案¶
2.1保持循环释放独立¶
mapserver和tinyows循环版本保持独立。
2.2向量网¶
在SVN上，Tinyows位置应为：
svn.osgeo.org/mapserver/trunk/tinyows svn.osgeo.org/mapserver/branches/tinyows-1.0 svn.osgeo.org/mapserver/tags/tinyows-1.0.0
2.3作为配置文件的通用 Mapfile¶
目标是能够为最终用户提供一个配置文件，所以是一个文本 Mapfile 。
Tinyows主干已经能够通过专用的mapfile lexer处理mapfile来检索所有的配置文件。
这个想法，在不久的将来，是带来一个libmapfile API，从而允许其他应用程序使用mapfile作为一个配置文件的方式。
它将简化这种解析器的维护，并避免具有不同行为的可能性。
此libmapfile api超出了此RFC的范围。
2.4透视图：打包构建系统¶
我们可以从这个RFC（以及相关的mod_geocache集成）中想象，提供一个具有单个配置/生成/生成安装的元包，同时管理mapserver、tinyows和mod_geocache的构建。
这些元包构建系统也超出了这个RFC的范围。
三。解决方案详细信息¶
3命名¶
Tinyows将被称为：mapserver Tinyows（保留以前的已知名称，并为其提供mapserver前缀）
3.1文件¶
将tinyows-trac-wiki文档移动到rst语法。
还需要增强文档以提供更多示例和全面的用户手册，或者至少类似于常见问题解答的内容。
当地的英国作家，还有那些还不熟悉这个项目的人，都非常感谢他们在这方面的帮助。
3.2许可证¶
Tinyows已经使用了MIT许可证，就像MapServer一样。版权所有人（芭芭拉·菲利波特和奥利维尔·科廷）应保存在现有的Tinyows文件中。
3.3张票¶
Tinyows使用Trac，但由于只有很少的票还处于打开状态，所以一种有效的方法就是在MapServerOne中重新创建它们。
应该意味着mapserver-trac中的一个新组件，称为：tinyows。
3.4开发人员和PSC¶
Olivier Courtin应该进入MapServer PSC并拥有对MapServer主干的提交访问权，并且将（至少在一段时间内）保持Tinyows开发方面的领先地位。
其他Tinyows开发人员已经参与了MapServer项目（Assefa、Alan）。
一个目标是让更多的MapServer开发人员准备好查看代码并提交补丁。
MapServer PSC将成为MapServer Tinyows模块的最终决策自动化。
3.6规范惯例¶
我们必须在整个代码中调用astyle，使其与mapserver兼容：astyle--style=kr--unpad=paren--indent=spaces=2
3.7重定向¶
tinyows.org域可以重定向到即将到来的mapserver tinyows文档页面。（http://www.mapserver.org/tinyows/）
邮件列表：应该停止tinyows dev和tinyows用户，并且应该对相关的mapserver用户进行新闻讨论。
3.8项目成熟度¶
如果我们与MapServer相比，Tinyows是一个更年轻的项目，有一个非常小的开发团队。因此，这意味着至少在一段时间内，项目的决策和管理部分必须保持轻量级。
因此，RFC必须只用于大的和主要的变更，所有其他常见的事情，都应该“仅”使用简单的trac票据，例如：
纠正/改进OGC标准的遵从性和互操作性
错误和安全修复
次要特征增强
小代码重构
单元测试策略
…
4。Tinyows代码检查¶
4.1代码起点¶
所有C代码都是由Tinyows开发人员从头开始编写的，因此不应该是真正的问题。
对于来自OGC的XSD模式和OGC引用单元测试：官方的OGC许可证描述如下：http://www.opengeospatial.org/ogc/document它允许公开传播，但不允许修改。
4.2代码质量¶
所有代码在通用类Unix平台上编译时没有任何警告，带有标志：-ansi-pedantic-wall
所有的OGC引用单元测试都经过了验证（没有错误，没有内存泄漏），但是它并没有覆盖所有的代码分支。
像CUnit这样的一些单元测试将来可能会有所帮助。
4.3安全审计¶
从未对代码执行任何外部安全审计。主要的固有风险是SQL注入。
一些检查已经用像sqlmap这样的自动化工具完成，但是需要改进以适应一些WFS-T和FE特殊的用例。
（在带有sqlmap的Tinyows主干上未发现安全漏洞）
4.4 OGC WFS-T合规性¶
实施WFS 1.0.0、WFS 1.1.0、FE 1.0.0和FE 1.1.0。基本和事务配置文件，SF-0。（未实现XLink或锁定配置文件）
- OGC上的Tinyows中继引用单元测试：
WFS-T 1.1.0（R4）：559'通过'/0'失败'
WFS-T 1.0.0（r3）：398'通过'/0'失败'
4.5外部依赖¶
libxml2>=2.6.20（和libxml2中继以避免GML XSD模式）
PostgreSQL>=8.1.0
Postgis>=1.5.0
FastCGI是可选的（但推荐）
4.6 Mapfile 概念尚未解决¶
- Tinyows中还没有出现一些 Mapfile 概念：
只处理PostGIS连接类型
Tinyows不会假装现在支持mapfile中所有可用的WFS参数
但另一方面，您应该能够从mapfile配置Tinyows的每个部分
层中的每个连接字符串值必须相同。
未分析 Mapfile 投影内容，因此请使用显式WFS_SRS
未分析 Mapfile 层/筛选器。
默认值是极小的，即使是两个应用程序共享的公共属性。
tinyows不使用mapfile中的数据元素，因此必须在每个层中使用tinyows_表（如果需要，还必须使用tinyows_模式）。
如果在一个层上dump未设置为true，则这些层的读写访问都将关闭。
4.7构建系统¶
Tinyows使用mapserver autoconf和makefile来构建东西。
4.8路线图和愿景¶
总体目标是使应用程序成为WFS-T可用的更快的替代方案，尽可能地符合下一个OGC和激励标准，当然，还具有健壮性。
- 主要的未来工作区是（他们将意味着未来的RFC，就在这里通知他们）：
添加新的导出格式（shapefile，kml…）
Apache模块支持
更详尽的单元测试策略（不仅是OGC策略）
Tinyows和MS的行为和配置指令更加一致。
Oracle空间支持
应用程序架构支持
WFS 2.0和激励合规性
5。投票历史¶
2011年8月19日，Steve L.、Steve W.、Tamas、Dan、Howard、Assefa、Thomas和Tom通过了+1。