Coordinate plans for libnifalcon development

[qdot]

@AlexJaeger @FabienDanieau

Just making a general issue for figuring out what to do next now that libnifalcon has multiple devs with push access. Right now I'm trying to get the documentation into the repo, and may update the project webpage to reflect the new links (I still get emails every so often from confused students looking for papers, heh). Would also be interested to know what you'd like to see done with the repo.

Honestly, I'd love to see this rewritten in C just because C++ was a mistake in the first place, though with C++11/14 it's certainly better than the state it was in when I was using boost. I still think it's way overcomplicated though.

I'd also like to take another crack at refining the kinematics algorithms, though that's gonna be pretty involved.

[AlexJaeger]

@qdot

Thats a good idea. I was one of those confused students at one point!

A C rewrite would be interesting from a compatibility point of view, particularly when it comes to tinkering with the falcon through Python or Matlab.

[FabienDanieau]

Re-writing everything in C may be a lot of work. Converting / refactoring in modern C++ could be more reasonable. We will have good performances, less lines of code (easier to maintain) and we will still be able to make Python or Matlab bindings.
Now @qdot you have the better overview of the current code. Did you see some limits that C will solve?

There are also two things we have also keep in mind before making a strong choice.
-> there is no more Falcon available on the market if I am correct. Meaning less and less users.
-> the open source library CHAI3D supports this device and it is cross platform.

My strategy would be to start by solving the issues and pull requests, and cleaning the code. By doing that we will see if there is a need to switch to C.
What do you think?

[qdot]

Yeah, the main problem is going to be API compatibility. H3D also has a libnifalcon support module, as well as HDAL (novint's driver) support module. Major problem here is that since I used boost for a lot of stuff (have I mentioned what a horrible idea that was :( ), the classes and signatures are already a mess, so I figured if we're going to break API, we might as well go all the way and make the simplest API possible, hence C. Then we could create C++ compatibility on top of that, but keep the core as simple as possible this time. Moving to C as a core also means it's far easier to bind to other languages.

I honestly have not looked at the code in years so I don't actually know how much work it would be. I still don't believe it'd be all that much, since most of the state can just be held in a struct and C99 is an option on windows now.

Outside of CHAI3D and H3D, I'm not sure where else libnifalcon is used, and I don't really want to break people, though this would end up being a v2.0 tag. I might pop into the H3D forums and see if their maintainers have an opinion on this.

Funny enough, I really do like Rust more than C but I'm not going to subject people to that. We'll do a libnifalcon-rs repo if that happens. :)

[qdot]

BTW, if you've got other stuff you want done on what's here now, don't let me stop you. Feel free to make/assign issues and start working. Mentioning a complete overhaul was a bit silly on my part, when people are just showing up to help on what's been here for years. :)

[qdot]

Also also, if I'm being too slow on stuff, feel free to bug me via issues or twitter (I'm qdot there too) or whatever. I'm heading up a few projects right now and can get somewhat distracted, but I definitely want libnifalcon up and running again. :)

[FabienDanieau]

What I meant with CHAI3D is that they don't use libnifalcon since version 3. They have their own driver.
But I agree, we don't want to break the compatibility with previous version of CHAI3D and H3D. If we want to do so, we may start a new 2.0 branch as you suggested.

For now I'll see if I can fix some issues.