[fdo-internals] Re: RFC 52 -- Convenience C++ API wrapper for FDO
Traian Stanev
traian.stanev at autodesk.com
Mon Aug 9 12:57:05 EDT 2010
Hi Jackie,
Answers below.
Traian
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Jackie Ng
> Sent: Sunday, August 08, 2010 8:47 PM
> To: fdo-internals at lists.osgeo.org
> Subject: [fdo-internals] Re: RFC 52 -- Convenience C++ API wrapper for
> FDO
>
>
> Hi Traian,
>
> Some questions/comments:
>
> 1. Are FIDs just in-memory unique ids for features? I was wondering how
> this
> would work for feature classes containing multiple identity properties.
It would not. For such classes, you can still access the values of the identity properties,
but the API intentionally assumes the 99% case of having an integer-ish feature ID.
>
> 2. Would this simplified API be easier to work with from a language
> interop
> perspective? For example, would it be easy to make SWIG or P/Invoke
> wrappers
> from this simplified API, or would a "hand-written" one be required
> just
> like the current API? I don't like the fact that non-Windows
> applications
> currently cannot use any of the existing managed wrappers as they are
> windows-only.
It would be easier to create wrappers in general, but they would have to be implemented manually. There is no way something like SWIG would generate sane wrappers to this code.
However, the API is very narrow, so doing it manually would not be a huge task (judging from how little it took to write the C++ code), and also can specifically provide nice language idioms of the higher level language, like index accessors, etc.
Also, the API as designed would have far less object lifetime issues like the .Net wrapper currently does. There is some proof that this API works well with higher level wrappers, but the proof is Javascript, so probably not relevant for .Net, but it means that it is possible.
>
> 3. I think that DatabaseDef needs an API to [Save to/Load from] XML
Sure. A working solution at the moment would be to use FDO schema XML, parse that with FDO and use the conversion function.
>
> All in all, I do like this simplified API
>
> - Jackie
> --
> View this message in context: http://osgeo-
> org.1803224.n2.nabble.com/RFC-52-Convenience-C-API-wrapper-for-FDO-
> tp5387309p5387470.html
> Sent from the FDO Internals mailing list archive at Nabble.com.
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
More information about the fdo-internals
mailing list