[cad-linux-dev] Re: dup: Drawing entity (8 bit)
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: CAD linux development <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Sat, 21 Aug 2004 14:13:55 -0500
# 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? =A0Also, 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 application=
s=20
have that much difference, I have to imagine that they would not be using t=
he=20
same format anyway.
Depending on the applications involved, you may have to access the drawing=
=20
through a layer of abstraction such as the sturgeon <-> rhizopod connector.=
=20
=46rom the user's point of view, this could be made transparent, but it mak=
es a=20
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=20
still more inclined to have a global version number, with sub-version=20
suffixes or something.
>Do you want to coordinate such a centralised standards track? I
>don't. =A0With 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=20
files within it are essentially an API. An API has a responsibility to sta=
y=20
interface-stable as much as possible, or the programmers using it will get=
=20
sick of chasing a moving target. That's the central idea of the=20
hub-is-a-node principle.
I've given up trying to imagine a drafting program and a relational modelin=
g=20
program using the same database. The drafting program would just go nuts=20
trying to keep-up with all of the complexity of the relational modeling=20
program. We can still have real-time interaction between the two if they ar=
e=20
using different databases, the databases just have to be connected (e.g.=20
rhizopod <-> sturgeon <-> dolphin.) Using the hub-is-a-node principle, we=
=20
can capture the complexity transition in the connector between the hubs and=
=20
save the rest of the connectors a world of trouble. Each node should conne=
ct=20
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 =3D=3D 0.5) and another at=20
($line_version =3D=3D 1.0) in the same drawing? If anything, shouldn't the=
=20
format have a global version number for each entity type?
I think the design for the rhizopod hub has to operate under the assumption=
=20
that there isn't going to be a whole lot of real-time interaction and=20
persistent-database usage. In the beginning, a lot of the usage is going t=
o=20
be import/export from/to monolithic formats used by ignorant applications. =
=20
With that in mind, it is going to be difficult to have persistent ID's for=
=20
the entities, so without a "search and re-associate" layer, this hub will=20
usually be created in a clean directory. (Note that the search layer is no=
t=20
impossible, but would likely be best implemented by using a temp directory.=
=20
This would essentially be an import/export functionality to Draft it is is=
=20
using the rhizopod hub directly.)
With that in mind, I think the format version will be globally tracked. Ea=
ch=20
connector will need to support all of the entities in order to prevent=20
data-loss. If your program uses the hub directly and only supports lines,=
=20
you simply have to map a range of "format version numbers" to a "line versi=
on=20
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 entit=
y=20
data structure. I could maybe see storing a set of <entity>_type_version=20
numbers in a global location, but I still don't think it is justified in=20
rhizopod. We've got enough experiments underway in this design already, an=
d=20
I think it just over-complicates things.
I won't rule anything out for sturgeon (or "mushroom" if you like), because=
we=20
aren't trying to write a spec for sturgeon right now.
Let's try this scenario as a more detailed manifestation of your above=20
'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=
=20
provided by the city authority, who has contracted with a surveyor that is=
=20
using microstation. The .dgn file is therefore imported as a block=20
(references to another rhizopod directory, where the (not search-aware)=20
rhizopod<->dgn connector reserves the right to delete and re-create=20
everything on each update.) The floor-plan drafter (user1) manually=20
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=20
building surfaces by building setting a relationship between the roof=20
drip-line and the setback line. This geometry is available in his=20
sturgeon-format directory by means of a "real-time aware" sturgeon<->rhizop=
od=20
connector which watches both directories for change and translates between=
=20
rhizopod lines (arcs, circles, etc) and sturgeon lines (etc.)
User2 relationally creates a floor-plan perimeter (at each level of the=20
Gehry-like building) and tells the connector to propagate this geometry int=
o=20
several rhizopod-format floor-plan drawings, but to set it as read-only.
User1 then manually references this perimeter to layout the walls and fixtu=
res=20
inside the building at each floor and sets-up a rhizopod->dwg connector to=
=20
get AutoCAD drawings which are sent out to the electrical subcontractors an=
d=20
etc.
When the city sends a new copy of the dgn street survey with different=20
property lines, User1 imports this into the street_survey/ directory with t=
he=20
dgn connector. The change appears in his drafting program, but the 15'=20
setback to the drip-line is now wrong. He makes this change, and the=20
floor-plan perimeters are now changed automatically because they are owned =
by=20
the 3D relational model. There is some manual work to be done on each=20
floor-plan now, and each of the subs must now change their wiring diagrams,=
=20
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=20
format-incompatible upgrade to the 3D relational modeling program? They=20
aren't. The sturgeon<->rhizopod connector must also be upgraded, or must b=
e=20
aware of the version issues. However, everything happens at the sturgeon=20
level and the rhizopod-format directories don't see it (unless the connecto=
r=20
is wrong, and then we're all hosed anyway.)
=2D-Eric
=2D-=20
"It ain't those parts of the Bible that I can't understand that=20
bother me, it's the parts that I do understand."
--Mark Twain
Other related posts:
- » [cad-linux-dev] Re: dup: Drawing entity (8 bit)
