[cad-linux-dev] Re: Drawing entity
- From: Bruno Postle <bruno@xxxxxxxxxx>
- To: CAD linux development <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Sat, 21 Aug 2004 17:49:09 +0100
On Sat 21-Aug-2004 at 10:48 -0500, Eric Wilhelm wrote:
>
> For starters, I'm just going to write-off mixed formats within a
> directory completely. I don't see it as even feasible that
> rhizopod and sturgeon would have identical structures and filename
> conventions.
Agreed.
If the "format" is the strategy for opening a directory/drawing it
does have to apply at a directory level. You have to know the
format before you can even begin opening files.
For the flat-directory format the strategy is "open every file with
readable extensions (.yml, .png, etc..) and try to assemble them
into a drawing".
For a format where geometry and styles are stored in separate
sub-directories, the strategy is going to be different.
> So, if $format is global to the directory, that leaves only the
> question as to whether $version is an entity-level variable.
Indeed, that's the question.
> Doesn't it sound easier to switch code classes at drawing-open
> rather than entity-open? Also, I know it is possible to write
> code to switch at entity-open, but is it worth it?
> What real-world situation justifies it?
Two people working directly on the same drawing but using different
software - The drawing could be shared directly, via CVS or they
could be sending each other diff generated patches.
If software A is more oriented towards graphic design and 2d
drafting and software B is more oriented towards 3d modelling and
rendering, they will both be capable of reading a different subset
of entities - This is fine, unsupported entities can survive
untouched and where there is overlap, collaboration can happen - The
directory-based concept is very resilient in this respect.
Say the developers of the 3d oriented application are actively
working on solid modelling and are rapidly changing their "solids"
entity structure, they really don't want to be resubmitting this
back to a separate "standards community" and persuading everyone to
increment community-wide version increments that are utterly
irrelevent to everyone else.
Do you want to coordinate such a centralised standards track? I
don't. With entity-level versioning, sub-communities can build
their own extensions without bothering everyone else.
The "line" element may never need to be changed and can stay at
version "eric1" forever, other elements may need many iterations
before they stabilise - If your application only suppports lines, it
doesn't need to worry about the versions of other entities.
--
Bruno
Other related posts:
