[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Fwd: Parts DB API: the story so far
John Doty wrote:
> 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.
>
>
I think the process is a bit more complex, or at least it is dodging the
issue of where these attributes are going to come from and how to select
them.
Yes an interface has to be defined.
Yes the attribute (or data structure requirements) have to be defined.
The point of the rdb engine over flat files is avoid writting a lot of
code to handle the flat files. Code that would be a lot of work and in
the end would likely be a rdb engine (in my opnion). Why not just use an
rdb to start with?
One argument against the rdb engine is not wanting to impose it upon
users (make them install it).
This argument can be over come by using an internet based system and
making the installation of the rdb engine optional.
Then there are those who would want local storage of the data, so
installing the rdb would have to be optional and being able to synch at
least downward from the network data to local data would be needed.
I am not a proponent for continuing the existing method of
distributing/using symbols, landpatterns and models.
I suspect that a lot of these issues really are next generation (libgeda
version 3) issues.
Thanks,
Steve Meier
>> 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
>
>
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user