I +1 Killerstorm's explanation. We absolutely need different Mastercoin implementations from the get-go to compare our interpretation of the spec. I already wrote an addition to the spec that should make comparing implementations very easy. For those interested you can read the
initial draft of the verification API here.
I (respectfully) totally disagree. Why is this necessary? Do we need 10 different bitcoind implementations to compare the interpretation of the bitcoin spec? If the Mastercoin spec is open to multiple material differences based on its "interpretation", then that tells me that it needs to be revised to remove ambiguity. Currently, it has a lot of that and I've started asking questions to help close that gap around some of these new features. I know you and many others have done a ton in this area, and I'm sure others will help out as well. However, some small level of ambiguity will still persist, so to your point, I agree that we maybe need 2 full parser/stack implementations, but not 10. It's simply not something that the average mastercoin developer should have to deal with.
In the world of bitcoin, 90%+ of developers just hang off of bitcoind. That doesn't stop anyone from developing their own bitcoin parsing tools (e.g. sx, and others). It's just dumb to require everyone to develop their own block parsers just to be able to do anything with bitcoin. killerstorm may say the parsing mastercoin transactions is so simple a monkey could do it, but I don't know the first thing about parsing multi-sig transactions, for instance, and I'm sure the vast majority of devs on this board don't either (nor do they care). If I was going to add value to mastercoin, I'd rather work on the
application I had in mind itself, rather than dinking around with bit fiddling to get my "interpretation" of the spec to show 907.3302929 MSC for transaction 3f04398298292fbcdd0f vs my buddy's showing a balance of 907.594029. Come on....waste of time.
Having each developer basically creating their own parser off the spec when we could have one mastercoind that 90% of devs use is not optimal, in my opinion. I'd think that we want 90% of devs on this creating end-user solutions that add
real value around mastercoin's awesome feature set, NOT more parser implementations that result in the confusion and issues we've been seeing lately between masterchest, mymastercoins, and master-coin explorer. Imagine that x100.
I say, if you're the 10% of devs that
want or need to create your own parser and spec engine, go for it. Otherwise, use mastercoind, hook into the realtime event feed, spend 10 minutes writing the code to parse apart the JSON for the events you want, and focus on your features.
That is the only way Mastercoin is going to win this race.