>> Cost vs.benefit. >> Cost: it's there, it's deployed. Everyone need to change, and we'll >> need to have backward-compatible files. > > I agree with you, keeping backward-compatibility will be costly, especially > without a good plan.
You might very well be right in absolute. Maybe the pure-YAML encoding would have been better. But this discussion is not about a new piece of code, it's dealing with the fact that there is software that was there for years and that is *in use*. Was this format the right decision ? At the time, it looked like it. If other people looked at it *at the time*, then it might have gone another way. But right now, it's there and has been there for, what, 6-7 years ? You've been actually using it for how long ? 3-4 years ? It's interesting that such an absolute ugliness did not show up on your radar earlier. Probably because, as a user, this discussion is irrelevant. Programmer cost, then. Migrating will be much more costly than the rewards we would get from such a change. The 30 minutes needed to write a parser (that should be written only once per programming language) *is* relevant. It has to be weighted against the cost of changing everyone's config files and habits with zero benefit / usability improvement on the user's side. So, what do we optimise for in this case ? For 5 programming languages, we're talking about 2.5 hours of work. Let's say half a day Assuming that changing all the config files and testing them is the same (30 min) per user and/or project (which is an obvious understatement, you're going to be dealing with new code) .... How many order of magnitude more than 5 users/projects do we have ? At least two ? If you really want to make a dent with the accumulated "wrong stuff" in Rock, I would be happy to provide you with things that could have a huge cleaning impact and little to no backward compatibility costs. They would however definitely require much more than 30 minutes of your time. Sylvain _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
