[cad-linux] Re: database application scenarios
- From: Roland Krause <rokrau@xxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Wed, 14 May 2003 14:55:11 -0700 (PDT)
Eric,
great! I believe it would be important to have your sketches, papers
and concepts, as well as you as a person on a team in some form.
My intent in rushing to sourceforge and setting something up is based
upone my experience that great ideas, discussions and threads often
loose momentum due to technical obstacles.
SF is relatively easy to use and learn, and it is well documented. So
just let me know when you are ready.
Regards
Roland
--- Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx> wrote:
>
> > The following was supposedly scribed by
> > Lee Fickenscher
> > on Wednesday 14 May 2003 04:12 pm:
>
> >Ok, I see your point. I was just trying to keep the work to a
> minimum
>
> That is understandable. I plan to do the same;-)
>
> >Do you see the library as using standard SQL to manipulate the
> database?
> >The reason I ask is that I feel it would be a huge benefit for a
> user to
> >be able to use which ever DBMS they may want to use (assuming that
> >database understands SQL)
>
> Sure, why not just have a DEFINE (I guess this would ultimately be
> handled by
> ./configure?)
>
> I think the work can be minimized by developing the access
> library/format
> standard as part of the modeling kernel. The kernel will need a set
> of
> functions to read/write the database, so making it a library from day
> one
> means that both projects are developing and there is a clear
> boundary/interface between the two.
>
> Also, say I want to write a perl script that polls the database for
> certain
> objects, gets some data from them, and adds some entities based on a
> few
> simple calculations and a "for($i=0;$i<10;$i++)" loop (or some such
> construct.) Do I want this to be a 500 line script that supports the
>
> standard on its own, or do I want to make a perl module out of the
> DB/standards library and have a 50 line script?
>
> Creating the library allows creation of high-level access methods
> which will
> allow companies to do simple in-house programming with very little
> overhead.
> Things that used to be done with macros or proprietary extensions can
> now be
> done with fast, cross-platform tools which have an enormous backing
> of
> modules, libraries, and packages (C, C++, Perl, Python, Tcl, etc.,
> etc.) So,
> instead of tying-up a high-end gui workstation with a VB script and
> having an
> operator watch the screen blink as all of the script's actions are
> performed
> at only 10times the manual operation speed, you run it from a
> console, or
> using whatever interface you have built for the simple batch process
> and it
> runs in 1/1000th of the time!
>
> >> Evolutionary pressure.
>
> >Dinosaurs such as M$, AutoDesk, and Tyranosaurus don't succumb to
> >evolutionary pressure, they fight until they are extinct.
>
> I understand that there will be some of these on the commercial side
> of
> things, that's why I envisioned using a VFS which presented a native
> file
> format to such reluctant apps. This would allow the "well, we're an
> AutoCAD
> shop" shops to use the system (albeit with some drawbacks from the
> app being
> totally unaware of the parametric features of the db) while in the
> transitionary stage. I see the investment that draftsmen have in
> knowing an
> interface as one of the boundaries to a universal system, so I hope
> that this
> can be addressed (in fact, I think it HAS to be addressed, or this
> will just
> be another system that can't talk to the ones which are already in
> use.)
>
> --Eric
>
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Other related posts:
