[snip]
> I am completely, utterly, and deadly opposed to a database, except as
> an optional plug-in -- i.e. a separate facility which the remainder of
> gEDA can run without.
[snip]
Agreed.
I'm more than willing to entertain code change proposals (no stealth
checkins of this magnitude without
I think the one missing thing is that we should somehow fix the
transistor problem, even in the "basic" configuration. Even if the
"simple mapping" we ship with only maps "PNP-1.sym" to "TO92" or
"SOT23" with suitable pin swapping, that would be sufficient.
I.e. choosing a footprint for a symbol
I wouldn't say we agree at all. I would say we have reached a
compromise. Not that either one of us had any real option. Plugins for
stock geda. Can I also ask that the dialog for pins allow one to select
if the pin is a bus pin or a net pin? Please?
The disagreement is about, if a database engine
Sorry, i didn't mean to come off as saying that one is required or
should be a core dependency, but SQLite is public domain, include the
source in your app distribute it how you will, near zero
administration, database system. that happens to use SQL so it is a
good leap board for larger SQL da
> I think you two are arguing different things.
>
> Stuart claims that REQUIRING a database ENGINE for ANY use of gEDA is
> bad for the project.
>
> Steve claims that ALLOWING a database SCHEMA for MANY uses of gEDA is
> good for the project.
>
> I think you can both be happy with a gEDA that MAY u
On Dec 26, 2007, at 10:40 AM, DJ Delorie wrote:
>> one word, SQLite
>
> The one word is "plugins".
Absolutely. If (for example) a MySQL or PostgreSQL plugin exists
for parts database access, I'd put all of my stuff in my (already
built, already backed up, already tuned, already in use for
Hi DJ,
You hit the nail right on the head :)
IMHO gEDA could do with a library of light symbols and the attachment of
attributes to the light symbols could be done with:
a) a simple attribute editor widget,
b) spreadsheet-like functionality (i.e. gattrib),
c) DB-like functionality (from flat c
On Dec 26, 2007, at 12:38 PM, Steve Meier wrote:
> Stuart Brorson wrote:
>> On Wed, 26 Dec 2007, Steve Meier wrote:
>>
>>
>>> Just to expand the vocabulary... two words..
>>>
>>> plugins
>>>
>>> translators
>>>
>>> I am convinced that the complexity of the data is better suited
>>> for db's
>>>
> > It is certainly true that if a DB is required to run gEDA,
>
> Thats an opinion or a belief not a proven fact.
I think you two are arguing different things.
Stuart claims that REQUIRING a database ENGINE for ANY use of gEDA is
bad for the project.
Steve claims that ALLOWING a database SCHE
Stuart Brorson wrote:
> On Wed, 26 Dec 2007, Steve Meier wrote:
>
>
>> Just to expand the vocabulary... two words..
>>
>> plugins
>>
>> translators
>>
>> I am convinced that the complexity of the data is better suited for db's
>> then flat files.
>>
>> Stuart is "deadly" upposed to requiring a d
On Wed, 26 Dec 2007, Steve Meier wrote:
> Just to expand the vocabulary... two words..
>
> plugins
>
> translators
>
> I am convinced that the complexity of the data is better suited for db's
> then flat files.
>
> Stuart is "deadly" upposed to requiring a db engine inorder to run geda.
*chuckle*
Just to expand the vocabulary... two words..
plugins
translators
I am convinced that the complexity of the data is better suited for db's
then flat files.
Stuart is "deadly" upposed to requiring a db engine inorder to run geda.
Plugins provides a solution to db or not to db.
I think it would
> one word, SQLite
The one word is "plugins".
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
one word, SQLite
I know a few OSX based applications that use SQLite as a back end that
users never have to even know about, (Aperture) it just does its own
thing.
what a data base gets you is speed of access to information and a way
to relate different type of information.
as for which databa
Stuart Brorson <[EMAIL PROTECTED]> wrote:
>> Trying to make the database optional even after developing its use
>> sounds hard. Is there opposition to a database? No database ever would
>> be limiting...
>
> I've been watching this discussion for quite a while. I don't want to
> derail it, sinc
On Dec 20, 2007, at 6:47 PM, Stuart Brorson wrote:
>>> However, our target user is a college student who wants to design a
>>> robot control
>>> board for his class (or as a hobby).
>>
>> Ur? That's news to me. I consider it a powerful tool that I
>> use
>> for grownup, commercial work.
>
>> However, our target user is a college student who wants to design a
>> robot control
>> board for his class (or as a hobby).
>
> Ur? That's news to me. I consider it a powerful tool that I use
> for grownup, commercial work.
That too. But the core of gEDA should remain accessible to co
On Dec 20, 2007, at 3:03 PM, Stuart Brorson wrote:
> However, our target user is a college student who wants to design a
> robot control
> board for his class (or as a hobby).
Ur? That's news to me. I consider it a powerful tool that I use
for grownup, commercial work.
-Dave
John Doty wrote:
> What are the makefile dependencies of a BOM in this database scheme?
> In other words, what's the information flow?
Depends on fictional, imaginary, futurist
database-query-tool, and gschem plugin capability.
BOM --> database-query-tool --> gschem-plugin --> .sch
.sch -->
> I'm failing to visualize this.
It's confusing because we're talking about TWO new things.
First, a database that has all mappings from light to heavy symbols.
Second, a BOM that contains the mappings you've chosen for your project.
> What are the makefile dependencies of a BOM in this databa
On Dec 20, 2007, at 1:06 PM, John Griessen wrote:
> Stuart Brorson wrote:
>> I am completely, utterly, and deadly opposed to a database, except as
>> an optional plug-in -- i.e. a separate facility which the
>> remainder of
>> gEDA can run without. If gEDA requires a database for use, then we
Stuart Brorson wrote:
> I am completely, utterly, and deadly opposed to a database, except as
> an optional plug-in -- i.e. a separate facility which the remainder of
> gEDA can run without. If gEDA requires a database for use, then we
> lose 99% of all gEDA users. A database is a PITA to install
I'll respond once and then go back to lurking. Anyway I don't have
anything more useful to say about this! :-)
On Thu, 20 Dec 2007, Steve Meier wrote:
> Wow, I am in the 1%.
Yup. Since you re-wrote libgeda to support features you needed, you
are definately in the 1%, perhaps in the 0.1%!
The
Wow, I am in the 1%.
Fair enough, when geda couldn't provide capabilities for hierarchical
buses I went out and implemented my own version down to rewritting hudge
chunks of libgeda (I am calling my derivative/fork libakeda since Ales
was concerend about confussion). I also have a second project t
On Dec 20, 2007, at 10:49 AM, John Griessen wrote:
> John Doty wrote:
>> On Dec 20, 2007, at 7:07 AM, Steve Meier wrote:
>
>>> 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
>> expre
Stuart Brorson wrote:
>> Trying to make the database optional even after developing its use
>> sounds hard. Is there opposition to a database? No database ever would
>> be limiting...
>
> I've been watching this discussion for quite a while. I don't want to
> derail it, since it's good to hav
On Thu, 2007-12-20 at 08:24 -0800, Steve Meier wrote:
> 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?
> Trying to make the database optional even after developing its use
> sounds hard. Is there opposition to a database? No database ever would
> be limiting...
I've been watching this discussion for quite a while. I don't want to
derail it, since it's good to have an exchange of ideas. However,
John Doty wrote:
> On Dec 20, 2007, at 7:07 AM, Steve Meier wrote:
>> 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,
> But that should be driven by something in the BOM universe, not the
> schematic.
I didn't say anything about schematics. I was referring only to the
backend API; it can be called by the BOM program (or pcb) just as
easily as it could from gschem.
_
Steve Meier wrote:
> 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?
Another important point is that it
[send]
symbol=resistor
value=1000
footprint=0603
vendor?
manufacturer?
My druthers
[result]
"vendor" "manufacturer" "vendor pertnumber" "manufacturor partnumber" "company
partnumber"
"digikey" "Susumu" "RP16S100FCT-ND" "RP1608S-100-F" "030-1000-23"
"digikey" "rohm" .
On Dec 20, 2007, at 9:57 AM, DJ Delorie wrote:
>
>> Because then we have to agree on an RDB and how to use it. Why not
>> just use a text editor to start with?
>
> We talked about databases at one of the freedog meetings. I proposed
> an API like this:
>
> Connect to some backend.
> Feed it attr
> Because then we have to agree on an RDB and how to use it. Why not
> just use a text editor to start with?
We talked about databases at one of the freedog meetings. I proposed
an API like this:
Connect to some backend.
Feed it attributes whose value you know.
Feed it a list of attributes wh
On Dec 20, 2007, at 9:24 AM, Steve Meier wrote:
> 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 rel
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 abo
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 user
>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
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
39 matches
Mail list logo
