On Sun, 2009-05-24 at 20:53 -0400, Duane Ellis wrote: > zach> [previous things] > david> > > Well, yes ... what eventually goes into /usr/include should > > be strongly limited to the interfaces. How anything gets > > implemented inside the library is nobody's busienss except > > for the library maintainers'. They should be able change > > how they do things easily. But that won't happen if all > > kinds of random implementation detail are cast in concrete > > as part of the public /usr/include interface to the library. > > > > Really, we need to think *STRONGLY* about *NOT* creating "libopenocd" > - I believe creating "libopenocd" will be a nightmare (ie: the > implementation details in concrete)
They might be a nightmare for you, but they do not bother me much. > I believe that a public *SOCKET* interface with a *TEXT* based > protocol to OpenOCD is a *FAR*BETTER* choice. Choice is what the library gives. Use it or don't (--disable-shared), but please allow the possibility that this will allow others to develop new solutions that would be impossible otherwise. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
