Re: gEDA-user: Parts DB API

[Levente <leventelist@xxxxxxxxx>]

Peter TB Brett <peter@xxxxxxxxxxxxx> wrote:
> [-- multipart/signed, encoding 7bit, 1 lines --]
> 
>    [-- text/plain, encoding quoted-printable, charset: iso-8859-1, 119 lines --]
> 
> On Wednesday 19 December 2007 09:52:49 Levente wrote:
>> Peter TB Brett <peter@xxxxxxxxxxxxx> wrote:
>>
>> [...]
>>
>> >> The symbol files should be as light as possible, and we should make them
>> >> heavy by adding information coming from the database.
>> >
>> > Totally agree.  Could we implement this by asking the backend to take
>> > care of where the symbols come from, and merge them with the database
>> > info before presenting them to gschem?  Or is this the wrong way?  Is it
>> > better to place a symbol, then invoke a special "select part" command? 
>> > My worry is that the latter option would make it easier to end up with a
>> > resistor which thinks it's an op-amp.
>>
>> I've started to implement things in the first way, but I think it is a good
>> idea to have it with the later. For example when you just want to make a
>> sketch schematic input, without any knowledge of what the exact part would
>> be. Like you place a resistor, but you don't know its value, type, etc...
>> Later, you can go round, and choose the exact parts from the database.
> 
> For anything more trivial than a resistor, these light symbols are going to 
> have to come from the database too, are they not?
> 
> How would this work for users who already have existing flat-file symbol 
> libraries they want to use alongside the database system?
> 
> How would this work for someone drawing a schematic of part of an ASIC for 
> simulation? (Totally different attributes etc. to those required of 
> the "expected workflow" you seem to be thinking of).
> 
>> Light symbols on the schematic (ones without attribute contents) should be
>> marked with some warning colour.
>>
>> Thanks to gEDA developers that symbols are not embedded in the schematic by
>> default.
> 
> I still haven't been convinced by these arguments, especially since _nothing_ 
> you've described can't be implemented with symbols which are embedded by 
> default. (So there. :P )

Ok, you might be right, but I think it is another issue. Yes, I confused the
attributes in the symbol file, and the attributes attached by gschem, after
placement. Sorry.

> My vision of how the database could work is as follows:
> 
> - Each symbol (or part) has to be uniquely identified by a string, and each
>  database/website/directory gets queried in reverse order of being added to
>  the library.  This is as currently.
> 
>  For databases, this could just be a concatenation of the database name and
>  some sort of unique identifier number.  The unique identifier string would
>  be stored in the schematic file where the "symbol name" currently is.
> 
>  This provides a way to store exactly which part was selected by the user
>  in a backwards-compatible manner.

Yes, but I think we should copy the information coming from the database to
have ability to read/process schematic off line, when there is no remote
database seen. Or did I interpret something wrong?

> - For searching for symbols, the user is presented with a GUI which allows
>  them to construct queries consisting of pairs of attribute names and values
>  in a list.
> 
>  (list 'regexp '("device" "*MOS*") 'and '("manufacturer" "IRF") 
>                                    'or  '("manufacturer "Philips"))
> 
>  Regular expressions? Glob syntax? Anything else needed?

Yes, something like this.

>  These queries are presented to the backends in order, and each returns a
>  list of matching identifiers.
> 
> - The current "in use" list becomes an "active" list, to which users
>  can add symbols at runtime either by placing a component or from the query
>  results view.
> 
>  The user could specify a default active list in the rc file for
>  commonly-used basic components.
> 
>  (define clib:default-active-list '("resistor-1.sym"
>                                     "capacitor-1.sym" 
>                                     "levente-opamp-lw"))

:-)

> - In order to select alternative parts from the database (e.g. go from a
>  generic op-amp to a specific Analog Devices low-noise rail-to-rail 5V amp) a
>  "compatible" mechanism is used.
> 
>  The user selects the component to be replaced, and invokes the "Choose
>  alternative..." command.  The user is given the opportunity to construct a
>  query as if choosing a component normally, except that the backends only
>  return parts which are compatible with the component's current identifier.

I fully agree.

>  If the user selects a part, the component to be updated will get replaced
>  with the new symbol from the backend.
>
>  "Old-fashioned" backends such as flat-files probably couldn't support
>  the "compatible" mechanism, but it is possible to imagine that databases
>  could provide lists of compatible parts for the basic symbols such as
>  resistors, capacitors and diodes from the default libraries.
> 
>  One tricky problem will be how to update attributes.  Database overrides
>  all?  Or some other method?

I think we should have some border between "Old-fashioned" symbols, light
symbols to be made heavy, and heavy symbols already updated from the database.
Then there will be no confusion.


-- 
Levente
http://web.interware.hu/lekovacs



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