1) Because of the "coded by hand" nature, the Managed wrapper API is almost always behind the C++ version. Cases in point: Missing methods/properties and the FDO Expression Engine. Us .net people still can't get to use them yet!
2) The current .net wrapper is not inherently "portable", in the sense that I could run a certain .net application using the current managed FDO wrappers in an alternate .net environment. This is because the current FDO wrapper is a mixed-mode assembly, meaning it is inextricably tied to windows. At least with the SWIG approach, things are done via P/Invoke which is a more portable method of managed/unmanaged interop (in that we can attempt to make it portable).
3) Not a lot of language variety. Only .net and Python bindings exist, which are both in in various states of neglected/lagging maintenance and cruftiness. There are some really useful java geospatial applications out there that can be even more useful with FDO integration! Also, a good swig wrapper can serve as a useful template for creating bindings to other languages in the future.
FDO is a wonderful and ambitious API. But for FDO to really succeed, I truly believe that it needs more than a .net wrapper.
Posts
3 comments:
Heh. The Python bindings are generated using SWIG, and at the time they were introduced Sean scorned them because they weren't Pythonic enough. Now you're scorning the managed bindings because they're not SWIG. Will you people make up your minds? :)
I am aware that python bindings are SWIGged, but as a swig newbie it's all gobbledegook to me at the moment.
Jackie, there's no help to it - FDO needs to be rewritten using .NET :-)
Post a Comment