# The following was supposedly scribed by # Bruno Postle # on Tuesday 24 August 2004 01:16 pm: >polymorphic inheritance. What exactly do you mean by that? Is the inheritance in types or references? If you are addressing individual files outside of a drawing, you are going to kill the "grep litmus test." I think anything to do with inheritance and references takes us too far towards relational drafting. That doesn't fit the rhizopod model. So, are you already designing the "sardine" spec here? If so, that's great, but let's define the separation and name the other sea-creature whatever you like, so we can start to see what a hub<->hub connector will look like. Alternatively, leave the more complicated issues out of Draft, and later evolve the rhizopod hub into something else. Rhizopod is characterized by the constraints of existing file formats because of the goal of using existing software in an interoperable way while also experimenting with the directory database idea and the concepts of decentralization, persistent addressability, etc. Ignoring persistence for a moment, we'll need the following functionality to work with minimal data loss. (note, each instance of the rhizopod format in this pipeline represents a clean directory.) dwg -> rhizopod -> dgn -> rhizopod -> pycad -> rhizopod -> dwg The differences between these three formats alone presents enough of a challenge, and none of them has support for any kind of inheritance or references to external entities. Including these things in the spec will lead to hair-pulling. Conceivably, persistence could be achieved by using a rhizopod<->rhizopod connector daemon which implements some kind of search routine, but this does not influence the design of the rhizopod spec. The rhizopod spec WILL have inherent persistence, but not when used with a non-persistent connector. I think the rhizopod spec needs to be held to the "grep litmus test" wherever possible. --Eric