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. :) > 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! Having a few alternate applications signed up to using the APIs would be the best way to make sure they're really "generic". - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
