Hi Jason,<br><br>Indeed you are correct in that one of the more interesting and challenging tasks is choosing between so many viable development options, thus the emphasis on key users such as yourself to advise our development is always welcome.<br>
<br>Historically, our relationship with FOSS has been very positive and mutually beneficial and we wish to continue those relationships and contribute there we are compelled and capable. Notably the emphasis of our involvement during previous projects has been to provide another framework for testing, feedback and support
rather than direct development. Our tendency is to help address specific features or feature sets for formats based on our users requirements.<br><br>Thus far, the adoption of Spatialite has not been overwhelming from our users though this has been a recent and late addition to the current release. In examples like this it behooves us to be cautious before committing to any development project. Certainly if we are motivated by our users I am convinced we will be
able to work out ways to improve this or other specific providers as required. <br><br>The noted inability to drop tables in a similar post is an example of a fundamental feature for a database format that certainly raises concerns for our users. Resolving these concerns are paramount to satisfying our users quality expectations and it is only hesitantly that we offer writing support without this feature. Thankfully these are always a work in progress. The official status of the provider is really more of a maintenance concern than anything else in terms of building from source or upgrading to newer versions.<br>
<br>As for versions, our current release, including Spatialite, uses FDO 3.5.0 and we plan to upgrade to FDO 3.6.0 once finalized.<br><br clear="all">ryan<br><br><div class="gmail_quote">On Thu, Mar 24, 2011 at 9:17 AM, Jason Birch <span dir="ltr"><<a href="mailto:jason@jasonbirch.com" target="_blank">jason@jasonbirch.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Ryan,<div><br></div><div>I know you guys are pretty maxed out on your developer time commitments, but I'm pretty sure that the FDO project would welcome more direct participation by Safe if there's any interest on your side.</div>
<div><br></div><div>Haris / SL-King are using the SpatiaLite provider with several clients, so there is some development impetus there, but apart from that there has been limited community uptake so most improvements thus far have been specific to SL-King's use. Safe's use of this provider would raise its profile for sure, but there may still be a need for extra help / resources to add additional capabilities.</div>
<div><br></div><div>The process of writing an RFC for bringing the provider into the official fold is a fair bit of overhead, but I'll see if I can find some cycles to do this and a PSC sponsor :)</div><div><br></div>
<div>When Haris addresses these issues, what FDO version are you targeting for compilation?</div><div><br></div><div>Jason<br><br><div class="gmail_quote"><div><div></div><div>On 23 March 2011 11:30, Ryan Proulx wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div>
Perhaps this is not quite the right forum, but despite being successful using the new SL-King SpatiaLite FDO Provider (version 0.1.2 as made
available <a href="http://www.sl-king.com/fdospatialite" target="_blank">here</a>) to read from SpatiaLite databases we have encountered a few issues with encoded column names when round tripping to and from SpatiaLite. <br>
<br>Using the provided sandbox source code, it appears that though the provider writes the encoded column name correctly, mapping the UTF-16 name in FDO to the UTF-8 string using the FDOStringP class, when reading the opposite mapping is not occurring. Instead in c_FdoSlite_API2::DescribeTableProperties there is an attempt to use the 'multibyte_to_wide' macros. These macros are ineffective in this context as they only widen the data type (from char* to wchar_t*) but do not change the encoding (from UTF-8 to UTF-16) as expected by the FDO. An alternative might have been to use the UTF-16 API calls instead but in the name of parallelism the FDOStringP seemed more appropriate.<br>
<br>I have provided a very simple patch file to correct the issue and if it meets with your approval would like to see it in the next version of the provider (if it has not been fixed already).<br><br> Do you have a rough estimate when we will see the next version of this provider or better yet become a complete citizen of FDO?<br>
<br>Thanks<br><font color="#888888">
ryan<br>
</font><br></div></div>_______________________________________________<br>
fdo-users mailing list<br>
<a href="mailto:fdo-users@lists.osgeo.org" target="_blank">fdo-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-users</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
fdo-users mailing list<br>
<a href="mailto:fdo-users@lists.osgeo.org" target="_blank">fdo-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-users</a><br>
<br></blockquote></div><br>