[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