[cad-linux] Re: CAD with server/client architecture
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Mon, 12 May 2003 18:03:32 -0500
> The following was supposedly scribed by
> raygr@xxxxxxxx
> on Monday 12 May 2003 05:51 pm:
>Borland's Delphi & Kylix (Delphi for Linux) apps are comparable in speed to
> C++. They are easier to learn than C++ especially for those of us who have
> learned to program in Visual Basic.
>
>Free versions of both are available. They have some minor limitations but
> are quite usable. Kylix uses cross-platform CLX components (controls),
> Delphi can use VCL components (Windows only) and CLX components (but only
> in the paid versions).
I'm not a big fan of Borland. I've worked with their C/C++ builder and I
don't think they are ANSI compliant.
>A possible downside is that Linux people have generally preferred C/C++ to
>Pascal (which Delphi is based on), so it could be harder to get support from
>most Linux programmers.
A bigger concern might be graphics programmers. Computational geometry is
probably easiest in C++, but there are plenty of libraries to support it in C
as well.
>I don't plan to learn C++, as I don't have the time and Delphi will be more
>useful in my job. However if this CAD app is going to be based on a database
>then any programming language should be able to use it.
I think this is a good place for SWIG to step in and provide a scripting
interface between (at least) Perl, Python, (some others I can't remember now)
and maybe a similar arrangement can be made to allow other languages to make
"system calls" to the core/kernel.
>It would be nice if everyone was working on the same project, but if not
>everyone agrees on which language to use then the options are either one
> project with a lot of moral but not practical support, or else a number of
> projects, some of which may succeed while some fail for whatever reason.
>
I think a number of projects tied together by a common core would be the best
way to get momentum. I could see providing some geometry-manipulation
functions in the core, which would allow the accessory programs to focus on
interface and specialty functions. This would allow faster development and
would build momentum faster (not to mention enabling companies to utilize the
system in-house for custom development.)
The "toolbox" approach would be very healthy for the CAD industry. Right now,
its kitchen-sink-this and kitchen-sink-that and no one system fully works
with any other. Creating a common core to handle the database would
facilitate the interoperability and creating a common kernel to provide
geometry functions would eliminate repeated work (I think openCascade is
primarily focused on this second task, so maybe components of it or existing
projects could be utilized?).
--Eric
Other related posts:
