[cad-linux-dev] Re: dup: Drawing entity version / format (last time)
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: cad-linux-dev@xxxxxxxxxxxxx
- Date: Sat, 21 Aug 2004 14:34:52 -0500
Sorry about all of these duplicates. This is driving me nuts. I've changed
the kmail setting from "quoted-printable" to "Allow 8-bit", but it seems to
be somehow dictated by the messages to which I'm replying, and the
mailing-list server always sends 8-bit. This has now been opened in vim and
re-wrapped, so it shows as going out at 7-bit encoding. Anybody know what
causes all of this?
I've already sent this to myself, and it shows as 7bit when I get it here. If
this still has equals 20 characters in it, the only way I'm going to get past
the listserver is to re-type everything that I want to quote?
# The following was supposedly scribed by
# Bruno Postle
# on Saturday 21 August 2004 11:49 am:
>> 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.
ok, but is this necessarily done through one directory? If the
applications have that much difference, I have to imagine that they
would not be using the same format anyway.
Depending on the applications involved, you may have to access the
drawing through a layer of abstraction such as the sturgeon <-> rhizopod
connector. From the user's point of view, this could be made
transparent, but it makes a huge difference to the code.
>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.
Possibly, but that situation also opens the standards to fragmentation.
I'm still more inclined to have a global version number, with
sub-version suffixes or something.
>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.
I think I'll have to. For starters, the shape of this filesystem and
the files within it are essentially an API. An API has a responsibility
to stay interface-stable as much as possible, or the programmers using
it will get sick of chasing a moving target. That's the central idea of
the hub-is-a-node principle.
I've given up trying to imagine a drafting program and a relational
modeling program using the same database. The drafting program would
just go nuts trying to keep-up with all of the complexity of the
relational modeling program. We can still have real-time interaction
between the two if they are using different databases, the databases
just have to be connected (e.g. rhizopod <-> sturgeon <-> dolphin.)
Using the hub-is-a-node principle, we can capture the complexity
transition in the connector between the hubs and save the rest of the
connectors a world of trouble. Each node should connect to the hub
which is most suited to it.
>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.
What if there is one line at ($line_version == 0.5) and another at
($line_version == 1.0) in the same drawing? If anything, shouldn't the
format have a global version number for each entity type?
I think the design for the rhizopod hub has to operate under the
assumption that there isn't going to be a whole lot of real-time
interaction and persistent-database usage. In the beginning, a lot of
the usage is going to be import/export from/to monolithic formats used
by ignorant applications. With that in mind, it is going to be
difficult to have persistent ID's for the entities, so without a "search
and re-associate" layer, this hub will usually be created in a clean
directory. (Note that the search layer is not impossible, but would
likely be best implemented by using a temp directory. This would
essentially be an import/export functionality to Draft it is is using
the rhizopod hub directly.)
With that in mind, I think the format version will be globally tracked.
Each connector will need to support all of the entities in order to
prevent data-loss. If your program uses the hub directly and only
supports lines, you simply have to map a range of "format version
numbers" to a "line version number" to know if you support the lines in
this particular version.
So, any way I look at it, I can't see storing a version number in the
entity data structure. I could maybe see storing a set of
<entity>_type_version numbers in a global location, but I still don't
think it is justified in rhizopod. We've got enough experiments
underway in this design already, and I think it just over-complicates
things.
I won't rule anything out for sturgeon (or "mushroom" if you like),
because we aren't trying to write a spec for sturgeon right now.
Let's try this scenario as a more detailed manifestation of your above
'2-user, 2-program' dilemma:
User1: 2D cad program connected directly to rhizopod.
User2: 3D relational modeling program connected directly to sturgeon.
User1 is responsible for the floor-plan and site-plan, but the site plan
is provided by the city authority, who has contracted with a surveyor
that is using microstation. The .dgn file is therefore imported as a
block (references to another rhizopod directory, where the (not
search-aware) rhizopod<->dgn connector reserves the right to delete and
re-create everything on each update.) The floor-plan drafter (user1)
manually references the site plan to maintain the 15' setback required
by the city.
User2 uses the setback line from the floor-plan geometry to tie-down the
building surfaces by building setting a relationship between the roof
drip-line and the setback line. This geometry is available in his
sturgeon-format directory by means of a "real-time aware"
sturgeon<->rhizopod connector which watches both directories for change
and translates between rhizopod lines (arcs, circles, etc) and sturgeon
lines (etc.)
User2 relationally creates a floor-plan perimeter (at each level of the
Gehry-like building) and tells the connector to propagate this geometry
into several rhizopod-format floor-plan drawings, but to set it as
read-only.
User1 then manually references this perimeter to layout the walls and
fixtures inside the building at each floor and sets-up a rhizopod->dwg
connector to get AutoCAD drawings which are sent out to the electrical
subcontractors and etc.
When the city sends a new copy of the dgn street survey with different
property lines, User1 imports this into the street_survey/ directory
with the dgn connector. The change appears in his drafting program, but
the 15' setback to the drip-line is now wrong. He makes this change,
and the floor-plan perimeters are now changed automatically because they
are owned by the 3D relational model. There is some manual work to be
done on each floor-plan now, and each of the subs must now change their
wiring diagrams, but that's what you get for not having a relational 2D
cad program.
In this scenario, how are the rhizopod-format databases affected by a
format-incompatible upgrade to the 3D relational modeling program? They
aren't. The sturgeon<->rhizopod connector must also be upgraded, or
must be aware of the version issues. However, everything happens at the
sturgeon level and the rhizopod-format directories don't see it (unless
the connector is wrong, and then we're all hosed anyway.)
--Eric
--
"It ain't those parts of the Bible that I can't understand that bother
me, it's the parts that I do understand."
--Mark Twain
Other related posts:
- » [cad-linux-dev] Re: dup: Drawing entity version / format (last time)
