Baby-Proofing ServerManager

• Difficulty accessing data on client side
  • Why do I need a representation to deliver data? I want data damn it! Give it to me!
  • UpdateVTKObjects() / UpdateInformation() / UpdatePipeline() / Representation::Update() what crap are you talking about? Just give me my data!
  • Maybe all we need is a vtkSMSourceProxy::GetData() method which internally can do whatever crap it wants to do with representations etc.
• Views and Representations
  • Everything should be VTK Views and Representations. We need to design how VTK Views and Representations can work in Client-Server/Compositing modes. Having subclasses beyond the core proxy classes i.e. vtkSMProxy, vtkSMSourceProxy, vtkSMWriterProxy, vtkSMViewProxy, vtkSMRepresentationProxy means we have screwed up.
• Simple XML
  • It must be possible to auto-generate xmls using some minimal annotation if needed. We need not actually implement auto-generation wizard, but it should be easily doable. If the user has to think at all when writing XMLs, then we have messed up.
• Domains
  • Domains are the one reason why writing xmls are complicated. It really hard to set up domains so that complicated properties such as array selection, block selection work. Any domain that has a “RequiredProperty” is just too complicated! “This has to update, then only the data-array are valid, argh no, that is not updated –aaaah!” – the common grievance. This should just not happen. Don’t know how we fix this, but we need to fix this.
  • UpdateDependentDomains() and all that stuff further complicates domains. They need to be updated, when do update them? Did I update already? Do I need to update? – just too much complication.
• Default Property Values
  • Properties need sensible default values, and these are not always determinable at compile time. Many a times the VTK-object is more capable to picking a default value – how can we make that work?