[cad-linux] Re: database access methods

> The following was supposedly scribed by
> Brian Johnson
> on Friday 16 May 2003 09:25 am:

>I thought part of the concept was to make the storage system easily
> expandable

yes

>I thought that the ability for an app to make it's own tables within the
> project db provided that.

yes

>I didn't think that the standard had to include a precise description every
> bit of data that anyone could ever possibly think of putting in the db

It doesn't.

>I also didn't think that for someone to add info that was not already
> specifically included in the standard complete with access library
> functions call to read/write to it would require the approval of the
> standard committee and and formal inclusion in the standard.

It woudn't.  It would be more like the way the Linux kernel is maintained.  If 
the functions are considered good and useful, they would become part of the 
standard library.

>I do think that this approach will kill this initiative since it would
> require anyone who wished to use it for data storage for any objects other
> than for what it is already designed to get "permission" (aka inclusion in
> the "standard") to be allowed to do so.

Not really.  You can't dictate what is going to be done with it.

>I can understand such a strict standard for parametric object data but if
> there is a project db, there is other info that would be useful in there
> that perhaps doesn't need such tight controls

Its not about control so much as structure.

>If there is a db per project, the ability to add additional tables for
> custom data is a really good feature.  Whether that additional data format
> is published or not (for other apps to use) should be irrelevant if it is
> stored in a separate table

If the additional data is stored in a way that makes it inaccessible to other 
applications, it hurts the "toolbox" approach of the system, because you can 
now only use the tool that created the data with the data.

>IMO, the "standard" should apply to the base tables required to get a
> working cad ui and should allow (how would you prevent this anyway?) and
> anticipate the addition of other tables

I agree.  I don't think you can prevent the creation of new tables, but I 
think you should do as much as possible to encourage developers to give 
access to the data.

I don't think a "working cad ui" is the point of the tables.  I think they 
(the standard tables) should provide a structure that facilitates the storage 
of parametric data in a way that is universally accessible.  The UI is 
external to this goal (db+kernel) and could come from any number of existing 
projects.

The idea of creating a library of access methods is to encourage a standard 
process for accessing the data, thereby encouraging interoperability and 
information exchange.  Sure, some program could come in and directly modify 
the database with proprietary data, but how does this help the collaborative 
design process?

If the library of functions is useful enough for every developer to WANT to 
use it as a starting point, and is LGPL'd:
It creates incentive to use the library
It gives an easy way of becoming compliant with the standard.
It encourages additions to the library, rather than extension of the database.
Additions to the library would be available to all of the apps which use it.
Using additions to the library, every app would grow and evolve.
As each component of the system evolves, competition increases.
As competition increases, apps get better.
As apps get better, MY life gets easier.

>I also still don't realize that native storage in a parametric format is
> "better" than storage of smaller building blocks and have a seperate table
> of the parametric objects that the "kernel" could use to mainpulate the
> smaller building blocks but perhaps that is simply because I can't fathom
> how it would work in my business where we do road design, sewer design,
> site design, building design, structural design, machine design, electrical
> design. 

I think the storage of building-blocks is the way to go.  However, to maintain 
the parametric relationships across multiple software packages, you would 
need a consistent way to represent these relationships.  If the modeling 
kernel is responsible for maintaining the relationships, how can a 
third-party modeling kernel "play nice" with the rest of the system?

>How can a parametric model be designed to handle all objects
> including drafting devices like text, tables, borders, leaders, etc

I think there will be some "stupid" objects and some "smart" objects.  
Providing locations for storing "stupid" data should be an integral part of 
the system.  It is not necessary to make text parametric (though it might be 
useful in some situations to "tie" the insertion point to some other entity 
with a parametric relationship.)  I think if you provide "containers" to 
store stupid data, that this allows creation of 2D drawings or 3D 
construction geometry which can be kept organized as part of the overall 
project.  Maybe the container is a "part" which can be dropped into a model 
or placed on a layout.  You could then use it for snapping by simply 
extracting the snap coordinates and making these explicit coordinates in the 
object being modeled.  

While it would be useful to have named construction entities that acted as 
controls for the model, this is not always the way people want to work and it 
would be hard to maintain the names and relationships when using a 2D 
drafting app that didn't know how to use them.  I think allowing "stupid" 
objects would work well enough, and would make the system easier to deal with 
in some cases (not to mention simplifying the 2D apps.)

--Eric

Other related posts: