Mail Archives: geda-user/2015/07/07/13:42:47.1
On 07/07/2015 12:05 PM, Evan Foss (evanfoss AT gmail DOT com) [via
geda-user AT delorie DOT com] wrote:
>> And this is another major reason: I love the idea that there is no database
>> involved and things are just files on my system, for the same above reason.
>> Maybe this wouldn't scale well if I wanted to have 10 million symbols - but
>> really, I am not even sure about that. Anyway in the scale I work, I'd have
>> 100x more problems with a database.
>> This is a good point too: I love how gschem and PCB are _not_ tied together.
>> I indeed miss back annotation, but I do not miss any shared database thing
>> between gschem and PCB.
>
> The Unix mentality these are all independent tools that we choose to
> combined this way.
Yes. This is not "80's technology" as someone said, any more than
cars are "early 1900s technology". Just because there were cars in the
early 1900s, doesn't mean all cars are from the early 1900s. The UNIX
many-small-specialized-tools approach was developed in the early 1970s
and has withstood the test of time; it continues to run most of the
world today.
> Most people have avoided binding them via a
> database because they want to keep things separate.
"Binding them" and "providing the facilities to bind them if the user
desires" are two very different things.
As an example of how this can be done, I point to a very successful
software package called Postfix. For those of you who haven't run big
networks, it's an email routing system that's in common use on the
Internet today. Postfix is a complex system; it's not uncommon for a
Postfix installation to involve as many as a dozen or more configuration
files controlling different aspects of its operation. This software can
be back-ended by any of a number of database systems for some of that
configuration data, for stuff that makes sense, like user accounts,
domain-name-based relaying permissions, etc. This makes maintaining
even a very large mail installation with hundreds of thousands of users
a breeze.
But it does not enforce the use of a database. Postfix can just as
easily be installed and be up and running in minutes with simple
configuration files for a handful of users on a private mail server.
This is an excellent approach if done properly. One might follow a
keyword-based "data sources" approach. For example, a component library
search path might look something like this:
/usr/local/geda/symbols;mysql:<authinfo>:<dbname>:<tablename>;/foo/bar
In this example, a path component can reference a connection to a
database, with embedded access control and db/table specification.
Or like this:
/usr/local/geda/symbols;~/.gEDA/mysql-symbols.conf;/foo/bar
In this setup, a path component can include a separate configuration
file which contains all of the metadata required to access the database.
(this is similar to the way Postfix does it)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
- Raw text -