>From the discussion, I am unclear on support for or against using a relational database to organize the data flow?
I do hear concerns about not having to rely upon a web bassed system. I do hear concerns about not wanting to require users to run a database engine. I have expressed concerns that the data isn't flat and thus isn't suitable for flat files. Thanks, Steve Meier Peter TB Brett wrote: > I initially posted this to -dev by mistake. DJ has already addressed item > #11. > > Peter > > ---------- Forwarded Message ---------- > > Subject: gEDA-dev: Parts DB API: the story so far > Date: Tuesday 18 Dec 2007 > From: Peter TB Brett <[EMAIL PROTECTED]> > To: gEDA developer mailing list <[EMAIL PROTECTED]> > > Hi folks, > > There's been some useful comments, but the thread's been slightly diverted. > I'd like to summarise what I understand to be the varying opinions so far. > Please tell me where I'm wrong. > > 1. I think that everybody agrees that _whatever_ is done must present a > simple > interface to the user, and be fairly straightforward for new users to work > out how to use. > > 2. I think that everybody agrees that the new system must be fully > back-compatible with the existing library system. > > 3. Several people would like assurances that the system will be generic > enough > to cope with workflows other than schematic to PCB layout (such as ASIC > design). > > 4. Most people seem keen on the idea of being able to place light symbols, > and > then later replace it with or turn it into a heavy symbol as required. > > 5. Lots of people railed at me about embedding symbols, for no apparent > reason. Cheers, guys. > > 6. I proposed the idea that most symbol placement should occur from a list > of "active" components, and that this list could be customised in the config > files. No-one seemed to object to this idea. > > 7. Some people preferred the idea of placing a light symbol, then populating > it with attributes from a database. Other people liked the idea of placing a > light symbol, then replacing it with a compatible heavy symbol, possibly > generated from a database. It was suggested that in the former case, the > database interface should be in gattrib rather than gschem. > > 8. Some people got side-tracked discussing the nature of attributes, and > whether attribute editing should take place in gschem or gattrib. > > 9. John Griessen was keen to make sure that everybody knows that he doesn't > like human-incompatible GUID numbers, and needed reassuring that he didn't > have to have any if he didn't want them. (I don't like them either). > > 10. John Doty is very keen on being able to set up libgeda to automatically > copy any symbols used to a local symbol store of some description. > > 11. Several people are keen on the idea of changing everything to use a > separate BOM as a master document. I don't understand what they heck they're > talking about nor how it would work, so I would like them to spell it out > carefully for stupid people like me. To me, a BOM is a spreadsheet, > generated from the schematics, containing a list of refdeses and part > information which is sent to an assembly house so they know which bits to put > where. > > Please post the url for the geda archives to DJ's response or explenation. > 12. I suggested a (fairly detailed) possible implementation, which was > largely > ignored, so I'd like people to go read it before they make any further > comments please. Message-Id: <[EMAIL PROTECTED]> > > Please post the url for the geda archives to the above email. > That's about it in terms of what's been discussed so far. Keep the ideas > coming please... > > Peter > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user