clicked the link and got "Error establishing a database connection". Not sure I can trust the source ;-).

Money can help get through the time you need to get back on your knees. I've had the misfortune of having my cofounder die after 18 month and two investments rounds and some money would have really help. Also you have to prepare for this kind of problems in advance because all of a sudden a substantial part of the shares of the company will be in limbo until the legalities are handled (and it can really stink if the family of the deceased is not helping...) which means: you can't raise money anymore, you can't really hire someone good as most people are very afraid of this kind of situation.

He had a scooter accident. My feeling is that he probably had the accident because he was really pushing himself too much: he was barely sleeping 3h per night and in the end his life was totally unbalanced with lots of prescription pills to support it (sleeping pills, caffeine for day time, weight loss pills, etc).

exactly!

The first time I picked the wrong co-founders (friends and all were engineers). The second time I picked the wrong project. The third time my co-founder died. The fourth time I wanted to do it alone but I almost burned out before my family started to send the signal that it was time for a change but I still think the tech and project are excellent though.

I tried and "failed" a couple of times in the last 14 years. Having a family pushed me to decide to settle down for some time. I started working as a software engineer at Apple a week ago. The itch is still there though ;-).

IIRC the lens profile format adobe uses for Camera Raw and Light Room is human readable and editable so you may be able to use it directly.

no, I rely on the fact that any version of an "eval" function should just no exist and that any text based protocol encourages the existence of such functions that can execute whatever is thrown at them, just because it sounds so easy and a quick shortcut in API design.

no, the problem is that you can treat any kind of text data as an executable. You can try to fix this by adding mountains of complexities and excuses but would still be true: as soon as you have text enter the equation you need to escape/encode/decode and parse. Every time you do that you add more complexity than is needed, and also you add many ways to abuse the programs and create "interesting bugs".

You are describing the problem exactly: it all too tempting to pass text around from user input to command line arguments without any way to validate the text data and assume it's ok because it's easy. It's exactly the same arguments that goes in between static and dynamic typing in programming languages: static typing ensures some sort of semantics is respected. If you pass text around, because it's easy and fast, most of the time you will never validate the data and you have no way to ensure that you are not actually handling a bomb. If the protocol was binary there is no way in hell you would be tempted to pass it's data without validation to an external program because you'd have to respect the API and because there would be not way to just send a bunch of commands. The same goes for sql injections, url buffer overflows, etc. Free form text should only be used for actual human textual data and should NEVER be the interface in between programs. It's way too fuzzily defined to serve as a protocol.

It's not about making protocols less understandable by humain, it's about recognising that we are programming computers, not humans and that it's time we accept that there should certainly be a way for the humans to interact with the program at some point we should not force the same kind of interactions on the programs themselves. It's much harder to make text and text based commands' parsing and handling secure than it is to use binary protocols in the first place.

It's an "internet tech" bug. Every developper should know how hard it is to parse textual data vs well defined binary in a secure and fool proof way. Yet every damn internet piece of infrastructure is based on handling textual data, mash it up, pass it around, escape and unescape it in hundreds of stupid formats. No wonder that most security troubles surfacing over the years are some form of abuse of this crazy design flaw: buffer overruns, sql injection, the openssl bug a few month back and now this. Let's go back to sanity and use well defined binary protocols where there is no damn way to send a command by text but only very explicit semantics, and stop the unix way of thinking that text should be more than a human interface. Text should never be used as a command language in between complex programs. Period.

Yes, and that's why one can wonder why they once again chose JSON for part of this new "web standard". Text based data formats should die.

I've been using the name for 13 years or so but a number of other libs started using the acronym unfortunately (New UI, Natural UI, etc.). I should have been more vocal and public about the lib from the beginning :-).

Kivy looks very nice but NUI is a very different beast (I'm the author). The main difference being that even though NUI is a complete multi-plateform framework that uses OpenGL for rendering, it has a strictly C++ API.

If you want to see apps built with NUI I just released reChord: http://bit.ly/rechord And also some very nice music apps with NUI: http://intua.net/products/beatmaker2/ http://www.whitenoiseaudio.com/apps/genome-midi-sequencer/ http://www.whitenoiseaudio.com/apps/bleepbox/