On Fri, 2009-12-04 at 23:31 -0800, David Brownell wrote: > On Tuesday 01 December 2009, Zach Welch wrote: > > We should approach this problem as though we intend to eventually > > decouple Jim from the core functionality and switch to a different > > front-end language. > > That's a useful statement of the extreme, but note that it's in > two parts: decouple ... and switch. > > Decoupling is one of those things that's not fully understandable > except in the context of concrete options. Without seeing a few > different front ends -- not necessarily languages, but perhaps > just custom JTAG tools -- it's hard to know how well decoupled > things really are. :)
Today, I started looking into the possibility of adding Lua for precisely this reason. I think it would be a good fit for us, and it would ensure that the decoupled APIs are both complete and robust. I think that calling Lua from TCL (and vice-versa) would be doable too. It might be scary and inefficient, but it would be interesting. ;) > > That would take a lot of extra work, but the > > preparation would yield solid architectural improvements to the system. > > Even if we never do that (and there's no reason to), the system will be > > cleaner for our efforts; it's classic model-view-controller separation. > > True, the cleanup is worth-while. But don't think that cleanup > is necessarily the same as decoupling ... or that all alternate > tasks want the same things decoupled! Yeah, the ZY1000 minidriver has shown that clearly in recent days; however, that gives rise to my claim that some couplings may be indications of fundamental flaws in the design of the structures and algorithms being used. > Having a few alternate applications signed up to using the APIs > would be the best way to make sure they're really "generic". A test suite will do this for us. That's one reason that I am pushing so hard for this. I won't bother to write one until things are cleaner, because it just means rewriting it... a lot. --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
