[cad-linux] Re: CAD with server/client architecture
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Sun, 11 May 2003 21:53:33 -0500
> The following was supposedly scribed by
> Jim Parker
> on Sunday 11 May 2003 07:14 pm:
>In GtkCAD, each primative has a seperate table and then there are
>tables for shared data such as verticies and vectors. In GtkCAD, a
>vertice is a location in space, which is different than a point. This
>general format also includes information on color, stipple and size,
>groups, layers, and parts.
>
This sounds similar to the DWG format (at least as it is presented through the
openDWG toolkit) where the entity is loaded as a structure, with all of the
attributes attached to it. It makes sense to me up to the point of groups,
layers, and parts, which I think should be separate tables. It seems like
knowing all of the entities contained in a part is a better way to store it
than which part the entity belongs to. If you had a table of layers, and
each layer in the table is followed by the list of entities on the layer,
wouldn't that make the grouping work better? A setup like this might also
help with data-locking and revision control, since you would likely want to
lock and update parts and groups and this would be harder to enforce across
multiple programs if they are not arranged that way in the database.
>Then I have another series of tables for engineering disipline specific
>data. For example Naval Architecture has it's own table, Mech Eng has
>another table(s), etc.
>
>Then Engineering modules will need another set of tables. For instance
>mesh data for CFD and FEA, hydrostatic data, etc. I am not sure how to
>handle CFD results. The files are huge for simple 2D cases.
>
I think the database should primarily contain _input_ data for the analysis
software. The results could be used to facilitate re-design of the model,
but the only programs operating on the results would be the analysis
programs, and then only to display them in a graphical (such as
stress-intensity field) representation. I think the results should be stored
with the rest of the data, but this is where the tarball-style file-format
becomes useful.
>Do you have an example format in mind ?
The thing I like about the openoffice format (using a tarball to store
multiple files) is that you can throw in a standard file-format, which has
already been time-tested, right next to the other data. If you want an image
stored with the file, just save it as a png (or whatever) right alongside the
other database files. For your CFD results, just use a well-defined flatfile
format which would then be easily accessible by other programs without having
to decipher a binary format. The main thing driving my love for the tarball
idea is the client-server part of the program-design model. I see the
concurrent-work process as requiring file-locking and revision control and I
think there would be a master-server which would be held by whoever "owns"
the design of the building/boat/racecar. The clients (subcontractor
engineers) would connect to the server, requesting the current revision
(read-only) of the design. The server would send them the portion which they
have requested (and are allowed access to (the electrical engineer doesn't
need the CFD results)). The client would act as a sub-server for itself and
the other workstations in the engineer's office and the tarball would
basically exist in an un-compressed format as a shared network drive while
anyone was working on it (of course a compressed, saved copy would be kept on
the hard-drive, with updates every 5min, so that backup-software could pick
it up for snapshots throughout the day, etc). If someone else on the project
requested an update from the electrical engineer, the latest version in an
"approved" draft state (there are some things that shouldn't be kept
concurrent, like when you are testing design scenarios) would be checked-in
to the master server so that the interference data could be checked. This is
just a scenario of what could be done with the open-source core handling all
of the revision control, connectivity, and database maintenance.
>One thing I do not like about
>my current data format is that color, etc. should be seperated from
>geometry information.
>
See my above comments on layers, etc. For color, maybe you should keep a
table of display attributes, or make it part of the material attributes
(texture, density, etc). Maybe a table of materials, and each entity has a
defined material associated with it. I would suggest trying to avoid making
the file-format optimized for display, but maybe color would not hurt, since
it would be commonly used between all applications.
>BTW do you know much about SQL databases ? I got some DB admin
>questions on how to best arrange my databases.
>
I've got a source, but I don't know how much help I could get out of her :)
--Eric
Other related posts:
