In case of functionality, I agree with Peter, however in case of a protocol I think it is much more important to have at least some minimalist hacked-together documentation, otherwise nobody will actually use it. At least the basic ideas about how it should work and what are the ideas for future extensions.
In the lack of documentation people won't start using it, because they don't want to rely on something that may change anytime or be removed. If it's at least somewhat documented and they can trust that it's not going to change from orange to cat overnight, they might. Also I didn't even know it existed until I accidentally stumbled upon it. Before I continue on the original subject I'll have to look into TCL a bit, so that I won't ask the wrong questions. If I'll have the time and energy I might start writing some code to make the interface usable. Just something to ponder on: Even though this applies mostly to the protocol, IMHO it applies to OpenOCD as well. OpenOCD is grossly undocumented, people don't like foraging in code to find out how a command works. If stuff were more documented, it would attract a larger user base and that in change might mean more developers. If people could add their ideas to the documentation with little effort (similar to a wiki page), then there will always be that 1 out of 25 that would. I for one would have added a lot of things in the past 2 years I have been using openocd, but it was not obvious how I could do it, and wasn't motivated enough to make the effort to find out how. And it would take only one user to ask the question, one developer to answer it, put that up on the according wiki/documentation page, and newcomers will have to make that less effort to use it. Make the effort once, and then save that time spent foraging in source code from a lot of people. Free up their time to develop something nice :). Also make OpenOCD more user-friendly. It's win-win IMHO. (Yeah, I know, I hate writing documentation too, but it's usefulness must not be underestimated - also a lot of traffic from the mailing list may be good enough to just copy-paste, and it's all going to waste more-or-less because the list is not as searchable as a webpage) Regards, Ákos Vandra On 23 May 2012 11:16, Peter Stuge <[email protected]> wrote: > Øyvind Harboe wrote: >> If we were to change the protocol, I'd want to see the new protocol >> completely documented before and a consensus before any code was >> accepted. > > I'd prefer seeing working code over documentation. Gerrit can nicely > manage a "long-lived" commit while it is being worked on and/or > tested. > > Who is using this protocol? > > > //Peter > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > OpenOCD-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openocd-devel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
