[freearchitecture] An open CAD file format

Steve Hall digitect at mindspring.com
Mon Feb 17 01:30:24 GMT 2003


Bruno Postle wrote:
 >

[CAD file format spec: file store concept]

 >

Still digesting this. It was a good read and I'm still trying to get
my head around it. Some random ponderings as I think:

* Not sure if the CAD file is in CVS or on my hard drive.

   If it lives in CVS, then file management from my hdd is irrelevant,
   I don't care about what it looks like there, I shouldn't even see
   it. But what if I want to mail it home to work on?

   If it lives on disk in zip format, I can easily put it to CD and
   distribute. But then what's to keep another user from referencing it
   and fowling up the versioning?

   It seems there's a conflict between CVS versioning and the file
   store idea. I can't figure out how to at the same time share the
   file as one glob, maintain locking for select atoms, and maintain
   its versioning all at the same time.

* Both this concept and the SQL idea acknowledge the need for the info
   to be stored in a fast, powerful database with maximum number of
   the tiniest info objects.

* Seems like both ideas also make file management secondary with the
   database primary. An SQL file format would require export. The file
   store uses a compressed package which seems to conflict with the
   need for (optional) limited internal locking for objects under
   current edit or reference.

* Not sure either would be as portable or transmutable as something
   like XML. It would be a shame to re-invent yet another data format
   when there are so many good XML code libraries already out there.

* CVS doesn't lend itself to thousands of tiny files. It's better with
   fewer files each containing a larger set of atoms. This seems at
   odds with the important notion that "multiple users can edit the
   same drawing at the same time."

* It would be nice to (somehow) fix the inevitable difficulties from
   hard-coding externally referenced data within a file that changes
   locations. Internal storage of definitions, while wasteful, should
   be an option. Of course if the file lives in CVS/SQL, the entire
   data set would be checked out each editing or distribution anyway.

* Persistent names seems ok as long as it's only for unique
   identification. Sounds like a trap to avoid if the embedded
   meta-data within the name gets used for anything else though.

* One line per data item--for readability or parsing? Same could be
   accomplished with XML or some folding tree thingy, too.

* Object properties stored in lookup tables is quite sensible.

* Blocks, Xrefs, groups and symbols are all the same thing--yes, in my
   mind, this it the one thing AutoCAD got right. Although I believe
   our new generation CAD file is already abstracting the data still
   further to include rasters, spec data, schedule, bid, etc., really
   anything.


Be glad to hear clarifications of my glob and versioning confusion.


Steve Hall  [ |digitect|(A)|mindspring|*|com| ]





More information about the freearchitecture mailing list