The "what" phase seems to have drawn to a close, so now it's time for the "how" phase. How do we do the things we want to do? What tasks will lead us to the features we want?
Here, in no particular order, are the tasks I think we need to undertake to get started (others will come up as we progress). If you were one of the proponents of one of these ideas, it's up to you to make sure it happens. Don't worry about "pretty" - just put together something that shows off the concept, so we can see it in action and evaluate it. We need to create a few small heavy symbol libraries. These are the self-contained "starter" libraries we talked about. Since these do not require any software changes, we should start on these right away. The purpose of these will be to give new users an opportunity to learn the editing tools without having to simultaneously learn how to make a library. These libraries should be packaged such that it's easy for the user to replace the standard library with them, and immediately be productive. gschem and pcb both need to be better at referencing multiple libraries of arbitrary depth. This includes a better way to manage the libraries (gui, config, query rules), enable/disable them, and browse them. This information should be sharable between tools, specifically, at least, between gschem, gnetlist, and pcb. While I do not wish to start a discussion about what kind of data should go in our "metadata", we need tools to work with it. I think that breaks down to the following: * On the database end, design an API or two with which we talk to the data servers. Implement a few servers to see how it works. I've started some ideas at http://www.delorie.com/pcb/component-dbs.html at the "How is the database stored?" text. * In gschem and pcb, we need a way to query the data servers in the attribute editors, in order to suggest attributes. * In gschem and pcb, be able to choose symbols/footprints based on metadata queries - use the metadata as a filter for the library dialog. * gnetlist needs the most work. It needs to be able to read a set of rules, query the database, and fill in additional attributes based on the rules. This need not be more than just "fill in the blanks" for now. gschem, pcb, and the sims need ways to query remote libraries. I suggest HTTP as the protocol, so we can use pretty much any web server out there. Gedasymbols is the obvious candidate, and I can work with whoever does this task to install any needed server-side logic. Someone needs to build a test library where the symbols have symbolic pin names, and the metadata maps those to physical pins in footprints. I suggest using the transistor problem as a basis for this library. Gnetlist will need to be modified to apply the mappings, although for this first step, there's no need to include pin or gate swapping information. Gschem and pcb need a way to swap variants on symbols and footprints, for example, switching between resistor-1 and resistor-2, or RESC1608N and RESC1608M. This depends on the metadata being available (above). Modify gschem's symbol chooser to allow filtering based on attributes within the symbol, not just the symbol name. I think it would be better if, at this point, people choose tasks and develop a quick prototype to (1) see if it works, (2) provide a basis for comparison against other potential solutions. Less talkie, more typie! ;-) Send a reply letting us know what you're working on, to make sure nothing gets left out. It's OK (in fact desirable) to have multiple people working on different solutions to the same tasks, so don't worry if someone else took your favorite. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user