[cad-linux] Re: CAD with server/client architecture
- From: "Brian Johnson" <bjohnson@xxxxxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Mon, 12 May 2003 21:39:48 +0000
Perhaps a wiki could be started to outline the specs and use the list to discuss
things? Does someone have one available?
I agree with your assessment of XML .. In addition, I would think multiuser
access
to XML text files would potentially slow down the system and create file locking
issues .. using a standardized SQL database makes it a moot point anyway
Jim Parker (hopeye@xxxxxxxxxx) wrote:
>
>
>On 2003.05.12 16:29 Brian Johnson wrote:
>>
>> I appreciate the excitment, but what db and what language is going to
>> be used
>
>
>GtkCAD uses a PostgreSQL database and the SQL module is written using
>ANSI C and ANSI embedded SQL. This was chosen for portability issues.
>PostgresSQL also has proper transaction processing, which other popular
>OSS DB's do not. Porting to, lets say, Oracle would be trivial, if it
>does not compile out of the box.
>
>The frontend is written in C using the Gtk+ toolkit. Nothing wrong
>with QT, I just don't use it.
>
>The graphics module was written in C interfacing with OpenGL.
>
>The math engine is the GNU Scientific Library.
>
>All my plug-ins will be written in C. Stuff like FEA/CFD, I will use
>system calls to programs like FELT, and create a module to write the
>proper input file, and to process output files.
>
>I do not know C++ and it is not worth it to me to learn it when I can
>write object-oriented code in C.
>
>I do not trust XML, M$ is already on record as saying all thier data
>formats will remain propietary with XML wrappers. IMO, XML is not the
>godsend everyone is making out to be.
>
>cheers,
>Jim Parker
>
>
>>
>> Perhaps a review (even if only a quick one) of the databases available
>> and the
>> creation of a desired feature list might be in order. MySQL seems to
>> be the most
>> popular and one of the fastest, but perhaps other desired features
>> would dictate
>> another db. Natixe XML handling might be a good thing for instance.
>> Also some of
>> the more advanced commit and rollback transaction abilities might be
>> beneficial.
>> Running on linux or windows or other OS a needed feature? Existing
>> good db
>> management software available? replication?
>>
>> Also, processing speed will be paramount for the main app. Is there
>> anything faster
>> than a C based system for that? Again, before we go too far, some
>> consensus should
>> be reached.
>>
>>
>> Eric Wilhelm (ewilhelm@xxxxxxxxxxxxx) wrote:
>> >
>> >
>> >> The following was supposedly scribed by
>> >> Jim Parker
>> >> on Monday 12 May 2003 02:42 pm:
>> >
>> >>Let me know if you want to take this discussion offline ... I am
>> >>tempted to send my data format to you to allow a more detailed
>> >>discussion of its merits.
>> >>
>> >I'm only a self-taught perl-hacker, so keep that in mind when
>> throwing tech
>> >stuff at me. Not that I can't understand it, but I likely won't have
>> time
>> >(especially in the coming weeks) to read through it all. I'd gladly
>> review a
>> >summary (diagrams good, C bad :)
>> >
>> >>I decided to leave Color/Stipple/Size information in the entity
>> >>structs. I decided the computational overhead of looking
>> >>searching/sorting the additional lists are not worth it. However,
>> it
>> >>should be noted that they are seperated out from the geometry data
>> in
>> >>the SQL database. So it should be trivial to extract just geometry
>> >>data for any module that may need it.
>> >>
>> >This sounds good. The program would need the speed-optimized
>> structs, but if
>> >you can draw a clear boundary around ... (see below)
>> >
>> >>As for the family of formats, my compromise is to allow each module
>> to
>> >>extend the format as needed internally, but all external
>> interactions
>> >>will use the standard format. This is dubject to change, but is
>> >>working well for the cases being tested.
>> >>
>> >If you can draw a clear boundary around each of the geometry and
>> other
>> >information types in your storage method, they could be translated
>> into the
>> >family of file-formats fairly easily. Each of the programs using a
>> universal
>> >kernel would of course load the data into memory in their own
>> preferred
>> >method, but a design like the one you are describing would be more
>> easily
>> >transferred into running on such a core.
>> >
>> >--Eric
>> >
>>
>>
>>
>
--
Brian Johnson
This is where my witty signature line would be if I bothered to edit this line
:)
Other related posts:
