[cad-linux-dev] uber-converter
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: cad-linux-dev@xxxxxxxxxxxxx
- Date: Sun, 6 Jun 2004 12:32:00 -0500
Here's a possible scheme for this plan:
http://ericwilhelm.homeip.net/uber-converter/hub_relation.dot.ps
The rectangles are file-formats, the ovals are (mostly) existing
libraries, and the hexagons are yet-to-be-written connectors.
Basically, we would use something like a cadfs (directory-database of
text files) as the core of the system (hub.) This is not necessarily
the case, but it would enable each of the converters to be written in
any language. If the central data structure is an sql database or
something else, we would need an api to enable the connectors to be more
easily written.
Why:
There are lots of existing cad, modeling, and engineering applications,
most of which cannot communicate with each other very well (particularly
in open-source applications.) If each application had to support
import/export directly for all of these file formats, then we are all
wasting a lot of time writing the interface between one application's
internal data structure and each file-format's data structure. Sure,
the code is open-source and anyone can use it, modify it, whatever.
But, if the code is too closely bound to the application (seems to be
the case quite frequently) then we are all shooting ourselves and the
rest of the open-source community in the foot.
The idea behind this scheme is that each connector is written only once.
e.g. instead of writing a dwg-lib to blender-lib connector and only
getting one-to-one file conversion, you write a dwg-lib to hub
connector, plus a blender-lib to hub connector. Thus, if you (or
someone else) later writes a vrml to hub connector, vrml is now
translatable to and from dwg and blender.
The wheel analogy works well here, since we are always talking about not
re-inventing the wheel. The central data structure is a hub, and each
connector is a spoke in the wheel. As each spoke is added, the wheel
begins to roll more smoothly and gain momentum.
The question which I would like to put to the list members is then: what
should be the shape of this central data structure? It must support the
union of features for all of the formats connected to it, so I realize
that this is non-trivial. However, we've been talking about a
directory-based structure and networked interoperability / simultaneous
access, etc here for quite some time. I think this is the place for
these ideas to be tested and begin to see some real-world usage.
It's been suggested that a mature tool such as pythoncad switching to a
directory-based format would be a good way for the format to gain
momentum, but this essentially means a thorough re-write of the
application, since real-time data changes were not expected in the
original design. A simpler path would be simply re-writing the file I/O
layer of such an application, in which case the real-time aspects go
away and we are back to a basic import/export operation. I argue that
we are no better-off with such a setup and that if we're going to resign
our existing tools to import/export operation, that we should put a
live/persistent database in place external to said tools, thus giving
the import/export functionality some degree of interoperability and
putting in-place the infrastructure for real-time shared atomic data. I
see this as the best pragmatic next step in the evolution of open-source
software.
--Eric
Other related posts:
