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

[Ryan Proulx]

Hi Jason,

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.

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.

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.

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.

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.

ryan

On Thu, Mar 24, 2011 at 9:17 AM, Jason Birch <jason at jasonbirch.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/e1cba546/attachment.html