Re: gEDA-user: Fwd: Parts DB API: the story so far

[John Doty <jpd@xxxxxxxxxxxxx>]

On Dec 20, 2007, at 7:07 AM, Steve Meier wrote:

> 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.

The maps within a relational database *are* flat, and may be  
expressed as flat files. I have seen such an implementation. So, I  
think this is a false dichotomy.

I think the issue at hand is to design an interface that allows the  
separation of textual information from graphics, and get something  
simple on the text side. We won't get to the perfect implementation  
in one leap. But with an interface, you can start thinking of how to  
hook your RDB in.

The critical thing is to be able to name sets of attributes, and then  
obtain them by name from something outside the schematic.

>
> 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 <peter@xxxxxxxxxxxxx>
>> To: gEDA developer mailing list <geda-dev@xxxxxxxxxxxxxx>
>>
>> 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: <200712191056.21450.peter@peter- 
>> b.co.uk>
>>
>>
> 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@xxxxxxxxxxxxxx
>> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>>
>
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user