[cad-linux] Re: database application scenarios
- From: "Brian Johnson" <bjohnson@xxxxxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Wed, 14 May 2003 20:34:39 +0000
I think both are desired .. an engine to provide pre-evaluated entities
(surfaces,
etc) AND use SQL to comunicate to the db storage tables
That way other apps that don't need geometry (or think they can do the geometry
better or faster) can access the db tables directly. Also, the choice of a
backend
database opens up as long as it supports SQL
Eric Wilhelm (ewilhelm@xxxxxxxxxxxxx) wrote:
>
>
>> The following was supposedly scribed by
>> Lee Fickenscher
>> on Wednesday 14 May 2003 01:53 pm:
>
>>The schema/data_definition would ensure a well-defined standard for the
>>layout of the tables. This may be where my confusion is coming from. I'm
>>thinking that the kernel would speak SQL to be able to interface with
>>whatever database was on the backend. Would this not be the case? What
>>would be the benefit of writing another library rather than just using
>>SQL?
>>
>
>Just using SQL leaves the method of storing the data up to the app. There are
>infinite ways to use a table to define a nurbs surface, and each app would
>need to be able to access it not as a table of data, but as a nurbs surface.
>While a well-defined standard would work, this would leave each app's
>developer to write a library of functions to access the data in that standard
>way, so why not make the standard into a library and have every app use that
>library? The easier it is to implement the standard, the more it will get
>used, and using a library creates a compliant method of implementing the
>standard, so it can be less loosely-defined (we don't want another VRML.)
>
>I see this library as containing functions like: get_type(address, *type),
>set_spline(properties, coordinates), or create_child(address, *parent).
>
>If this database is going to support parametric objects across multiple
>programs, it is going to be a complex set of links, values, parameters, and
>properties. Defining a standard which could be easily implemented via an
>LGPL'd library would ease "porting" the application to this database
>system/platform and ensure the integrity of the standard.
>
>>While I think comercial vendor support would be great, and you may get
>>support from many small vendors. I don't think you will ever get
>>AutoDesk to jump onboard. They are like M$, its the whole pie or...
>>well, it just better be the whole pie... :-)
>
>Evolutionary pressure. I'm not after the small vendors with these ideas. I
>guess I'd better have the whole pie too, but I want it to be an open pie:)
>Linux would not be taking over the world without the stability, speed,
>extendability, and power provided by its design and implementation. If this
>system does the same thing for cad/engineering software that linux has done
>for operating systems, the interest will be there from large and small
>companies, users and developers.
>
>--Eric
>
--
Brian Johnson
This is where my witty signature line would be if I bothered to edit this line
:)
Other related posts:
