[fdo-users] SL-King SpatiaLite FDO Provider - encoding issues with column names

[Jason Birch]

Hi Ryan,

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.

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.

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 :)

When Haris addresses these issues, what FDO version are you targeting for
compilation?

Jason

On 23 March 2011 11:30, Ryan Proulx wrote:

> 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 here <http://www.sl-king.com/fdospatialite>) to read from
> SpatiaLite databases we have encountered a few issues with encoded column
> names when round tripping to and from SpatiaLite.
>
> 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.
>
> 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).
>
> 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?
>
> Thanks
> ryan
>
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-users/attachments/20110324/8ec92ea8/attachment.html