[cad-linux-dev] Re: uber-converter

  • From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
  • To: cad-linux-dev@xxxxxxxxxxxxx
  • Date: Tue, 8 Jun 2004 15:02:45 -0500

# The following was supposedly scribed by
# Lee Harding
# on Tuesday 08 June 2004 02:20 pm:

>Did you even look at the translation kit docs?

For starters, I'm not sure what "The folks at dear, departed Be, Inc. figured 
this out already" means.  Did they figure out that a circle can or cannot be 
represented with a single data-structure and converted to and from multiple 
existing formats?

Looking at your previous emails referring to the "media roster" and the fact 
that it meant you didn't have to write import /export code, plus that it 
handles chaining automatically, and etc:

  Why does this mean that there shouldn't be a hub?

The problem with using chains of converters on cad/engineering data is that 
you are always going to be limited by the weakest link in the chain (the one 
supporting the fewest entities.)  The idea here is that if a hub can be 
created which supports all of these entities, that the middle link of the 
chain is never the weakest.

Furthermore, instead of having to rewrite applications with "media roster" 
support, the hub-spoke model allows existing applications to be used while 
the UberFoo hub and editors are maturing.  What's the ship-date of the 
autocad version with UberFoo support?  I'm sure the same goes for most 
applications, even open-source ones that want to switch to a cadfs data 
storage model.  There is a lot of code to re-write before you are saving in a 
new format, and you have to remain reverse-compatible.

This model provides both transition and unification.  A tool-chain model might 
get us unification, but leaves us waiting till infinity before we have 
cross-vendor interoperability.


Other related posts: