Table of Contents
Unified Metamodel based model library
hg clone http://rcs.kyanite-studios.org/hg/metamodel
http://delcorp.org/~caedes/metamodel_test.tar.bz2 → 3d model test using pygame and opengl
Goal: To have a model library, offering automatic serialization and synchronization using different backends. Models would be defined based on one unified metamodel, and they would get all the features for free, while keeping the model access natural from the application.
Todo
- Data sources:
- Probably some layers to allow serialization+svn to track revisions.
- xmpp (halfway done)
- trac tickets
- data transferral protocol among datasources.
- Add more property types.
- Lists with references or some kind of values
Open problems
- More expressivity on properties
- how to express a class has a number of slots which are constrained by childrens? This happens on cs materials for example, where the texture slots are constrained by the used shaders.
- how to express and handle properties of anytype? How to make the type depending on some other property? For example the value on animation channels depends on the property we are animating.
- how to refer to a property in some target model? PropertyFrom(“otherproperty”) looks ok?
- how to refer to an object constrained by some choice on a parent node? For example, on quests, you normally have to select property classes from certain entity, or a property from the quest entity. Maybe this is the same problem as previous point.
- Node urls. How to locate a node when the datasource is not there yet? At the moment, one must know which datasource to use for nodes which are linked from other datasource, but there is no hint about which it is.
- How to do links, as in html links, where a link to a new context is provided, and clicking on it will suck new data and possibly relocate the view.
- We can have name clashes because we refer the classes only by their name, not their namespace+name. This starts to be a problem since we have a lot of MMized classes – dukez
- About the views, I think it can be done in a better way : One class for the master view (the current BaseModelView) which can register slave views (currently ViewBaseObject). The first one would not propagate the signals to the upper level by default (but could if needed) while the other would propagate them in the higher hierarchy until we reach a Master view. – dukez
Todo-low priority
- Dead reckoning/Interpolation/Extrapolation
- Where goes auth?
- Where to define “business rules”? (like what are valid operations on the “world”)
- How to fit in component messages and interaction?
"related"
- http://instructionaldesign.com.au/Academic/TechnicalTheme1.htm What is the Technical Basis for the Semantic Web?
