Hi Burlen, The functionality is indeed great. The only hesitation I have is with burdening server manager code with another serialization code. My comments are inlined.
>> One substantial difference is that connection id is central in the state >> implementation. however not only is it not needed for configuration but it >> cannot be used with configuration. So for configuration the lack of a >> connection id is a central feature. Not necessarily true. If you look at vtkSMProxy. It has a method LoadState() which simply takes in the XMLElement to simply load the given state on the proxy. If you look at vtkSMDeserializer (the base class for state loaders), by providing a right locator to locate the proxy that the state XML is asking for, the connection id doesn't even come in the picture. Further more, you can easily provide a totally separate state loader class for the configuration without having to add any thing to the properties, proxies >> Another distinction is that the state of domains aren't needed by >> configuration. Honestly domains should not be saved in the normal state as well, since we never load them back. But I agree with you that your configuration files are much easier to edit and read. An alternative solution would be keep that code isolated i.e. we don't really need to add the Save/Load methods to vtkSMProxy, vtkSMProperty etc. for the configuration, you can always simply get/set the property values in your serializer/loader classes. What do you think? Utkarsh _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
