That's a possibility, perhaps using ruby's ffi bindings, assuming it doesn't hurt performance and keeps the existing API. It sure could make things nicer for adding functionality and could open the code up potentially to a new audience who aren't familiar with hacking at ruby at the C level. I have previously done an ffi library, having converted the old ruby gd2 bindings library from using dlopen and friends to using ffi (see the gd2-ffij gem), so I'm familiar with the process. Something to think about for sure... Dammit, I think my weekend might have just been ruined, thanks for the idea. :)
Sent from my mobile On 2010-12-01, at 1:48 PM, Charlie Savage <c...@savagexi.com> wrote: >> I don't really know how much maintenance would be required going >> forward as the Ruby bindings seem are quite stable. Perhaps this sort >> of release will foster some interest in new features in the bindings >> themselves. For our part, we've never had to patch away at the >> bindings directly and have been putting all of our extensions into the >> separate gem we'll be releasing, so that's kind of a separate thing. > > In a perfect world, I would probably rewrite the Ruby bindings to not use > SWIG because that makes it really hard for others to contribute due to SWIG's > learning code and the awful C code it generates. > > However, its not that big of a win as long as the current bindings expose > whats needed from the geos c api and then any extensions/additions/language > specific stuff is done in regular ruby code. > > But if you have a week to kill J, I think it would be a nice change :) > > Charlie >> _______________________________________________ >> geos-devel mailing list >> geos-devel@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/geos-devel > > -- > Charlie Savage > http://cfis.savagexi.com _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
