[cad-linux] Re: database application scenarios
- From: "Brian Johnson" <bjohnson@xxxxxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Thu, 15 May 2003 03:45:43 +0000
I think the proper response is an absolute "it depends"
How do we know what apps will be developed?
How do we know that someone who has a better/faster way to process the data
will be
willing to provide it as open source?
How do we know a lot of things? Using SQL as a transfer method provide another
way
to get the data and in some cases it will be better (even if we're only talking
about counting how many doors are used).
As stated, it will also open up the possibility of using other db backends (some
places are stuck on Oracle for instance)
Eric Wilhelm (ewilhelm@xxxxxxxxxxxxx) wrote:
>
>
>> The following was supposedly scribed by
>> Brian Johnson
>> on Wednesday 14 May 2003 03:34 pm:
>
>>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
>
>There would of course be nothing to stop a developer from using their own
>access method for the database, but I think providing a library which
>facilitates the access would tempt developers to stick to the standard
>library. Its not really a matter of whether they can do the geometry better
>or faster, because it would still need to be stored in the table in the
>standard way. So, the only benefit of foregoing the library would be if you
>can access the database better or faster. But, wouldn't modifying the LGPL'd
>library give you a good enough starting point to implement these speed
>improvements? And wouldn't having the access-speed improvements made to an
>open-source library benefit everyone involved? Take KHTML as an example.
>Apple used this as a backend for safari, making speed (and other)
>improvements which were then released back into the open-source project.
>
>--Eric
>
Other related posts:
