> >> Peter C. and I are working hard to give PCB an interface > >> that can be used to > >> talk to it quickly and easily. We don't want to have to > >> maintain a huge chunk of code to do so -- a chunk of code > >> which would almost certainly suffer > >> heavy feature creep and need quite active maintenance.
Please think beyond just PCB and gschem. All of the applications need to communicate. On Saturday 07 October 2006 14:18, Dan McMahill wrote: > dbus-0.9.3 + some patches has 95,732 lines of code which is > 12 lines shy of matching whats in the clipper branch of pcb > right now. Gnucap is half that size, including the model compiler. > > Stuart Brorson wrote: > > On the other hand, if you create a stripped-down version of > > DBUS, you (we) control it, and it won't change and become > > obsolete as future generations of hackers work on the stock > > distribution of DBUS. > > and we become the ones responsible for dealing with > > a) getting it to work on all the platforms that we'd like > pcb to run on > > and > > b) security fixes. We are responsible for that anyway. It is possible that the overhead code needed for DBUS exceeds what would be needed to just do the job in a simple way. Before even thinking about what library to use, we must first decide what communication we want to accomplish, and how to present it to the rest of the program. Whatever library is used, it should be presented to the rest of the program, and others, as high level calls that are meaningful in the context of the application (printed circuits, schematics, simulation, etc.) Even if such a library is used, it should be encapsulated with a single pair of files to present the desired interface. That same pair of files can be used for any gEDA family application. If later it is decided to switch to a different library, or the one we use changes, only that pair of files needs to change. That interface should be designed around what we want on a high level, almost without regard for the underlying library. In time, it could even support multiple libraries, with almost no additional effort. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
