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

[John Doty <jpd@xxxxxxxxxxxxx>]

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

I don't agree that we need a lot of code here.

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

Because then we have to agree on an RDB and how to use it. Why not  
just use a text editor to start with?

>
> One argument against the rdb engine is not wanting to impose it upon
> users (make them install it).

It's one more dependency that will break installations. gEDA already  
has too many of those.

>
> This argument can be over come by using an internet based system and
> making the installation of the rdb engine optional.

Designing and implementing that is nontrivial. And I don't want to  
depend on the internet for schematic editing: I do a fair amount of  
that off line.

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

More complexity. But let's get the interface so you can go ahead and  
do this if you want. But I don't want to wait for some complex thing.

>
> I am not a proponent for continuing the existing method of
> distributing/using symbols, landpatterns and models.

Well, again, you get into another knotty issue. But let's try to keep  
these things disentangled. Our developers are superheros, not  
hyperheros ;-)

>
> I suspect that a lot of these issues really are next generation  
> (libgeda
> version 3) issues.
>

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