<HTML>
<HEAD>
<TITLE>Re: [Paraview-developers] Plans for changes to ServerManger (Paraview 4.0 or later)</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>The simplification of the SM class hierarchy sounds very nice even if I have not completely wrapped my brain around it. Given that, perhaps this is a good time to take a critical eye on the client/server interface of the ParaView Server Manager. Right now, the XML definitions are pretty chaotic (particularly those outside of readers, filters, and writers). I think it makes sense to make a pass to simplify and perhaps even constrain the interface. This could help maintenance as well as make it easier for users building plugins, vertical applications, and coprocessing adapters.<BR>
<BR>
-Ken<BR>
<BR>
<BR>
On 7/14/10 2:58 PM, "Utkarsh Ayachit" <<a href="utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Ken,<BR>
<BR>
> One advantage I see of the new technique is in using a debugger. Debugging<BR>
> is mentioned, but with respect to logging and tracing. However, I’m more<BR>
> excited about being able to look at a snapshot in a debugger and trace back<BR>
> what client code instantiated it. An additional feature could be a debug<BR>
> mode that “synchronized” the client and server. That is, it makes the<BR>
> client wait until the server is finished processing each PushState or<BR>
> Invoke.<BR>
<BR>
Great idea. I've added that to the Wiki page so we can keep it in mind<BR>
as we implement it.<BR>
<BR>
> I’m not entirely clear how the change encourages developers to use VTK<BR>
> objects directly. Is it because the code that is now in those many<BR>
> vtkSMProxy subclasses (e.g. the representations and views) moves to the<BR>
> server as vtkPVObject subclasses? Do the original vtkSMProxy subclasses go<BR>
> away? (It sounds bad to have to pair them up.)<BR>
<BR>
As a simple solution, yes, all code in vtkSMProxy subclasses can move<BR>
to vtkPVObject subclasses. But a cleaner solution would be move that<BR>
code to a vtkObject subclass instead and then simply use that. Having<BR>
a large number of vtkSMProxy subclasses like we currently do is<BR>
turning out to be a nightmare. When a large number of sub-proxies are<BR>
involved (look at representations/views) the code in inevitably<BR>
unreadable. All those can be rewritten as vtk-level code directly in<BR>
most cases. I am currently working on vtkPVRenderView that is a<BR>
vtkView subclass with all client-server/parallel communication<BR>
encapsulated with no major need for special code in vtkSMProxy. We can<BR>
very well design almost all other vtkSMPRoxy subclasses that way.<BR>
Ideally, you are correct, all vtkSMProxy subclasses should just go<BR>
away (except may be vtkSMSourceProxy).<BR>
<BR>
> If the vtkSMProxy classes get rearranged/deleted, how does that effect how<BR>
> the XML definitions are parsed? Currently, there is some magic that takes<BR>
> XML tag names, mangles them into VTK class names, and instantiates a class<BR>
> of that name. How will the new class hierarchy effect that?<BR>
<BR>
Definitions will have to change to reflect the new class name to<BR>
create. So for a view, if we get rid of vtkSMViewProxy, the XML<BR>
definition unfortunately will have to change to use just <Proxy /><BR>
instead of <ViewProxy />. To tell what PM object to create for that<BR>
proxy, we can add a new optional attribute something like<BR>
pmobject="vtkPMViewProxy".<BR>
<BR>
> If the new implementation relies on Google protocol buffers, does that mean<BR>
> you need to install this in order to compile ParaView? What happens if you<BR>
> want to compile ParaView for, say, the Cray XT or BlueGene?<BR>
<BR>
We have a cmakified version of protobuf. Protobuf does not have many<BR>
external dependencies so don't see any reason why it won't compile on<BR>
a machine where ParaView compiles. Since protobuf is BSD, we will<BR>
include it as under ParaView/Utilities itself so users don't have to<BR>
install/build is separately.<BR>
<BR>
> What is the granularity of the data pushes. Is the state from multiple<BR>
> proxies pushed in the same message? I would expect there to be too many<BR>
> messages otherwise.<BR>
<BR>
Every time a vtkSMProxy::UpdateVTKObjects() gets called, it will try<BR>
to push its state for all the modified properties. All PushState()<BR>
calls are routed through the ProcessModule. The ProcessModule can<BR>
buffer these PushState() calls until buffer fills up or Flush() or<BR>
PullState() or GatherInformation() happens. Since there's no arbitrary<BR>
GetLastResult() or such call on ProcesModule anymore, such buffering<BR>
is feasible. Even without buffering, however, this won't be any worse<BR>
than what currently happens in ServerManager.<BR>
<BR>
> What is the role now of vtkSMProxy? If all the logic is moving the the<BR>
> server side, does this class provide anything but a hollow wrapper around<BR>
> vtkSMRemoteObject?<BR>
<BR>
vtkSMProxy is client-side state holder for the vtkObject. We are<BR>
moving the VTKObject updating logic out from vtkSMPRoxy. It still<BR>
provides the facade to the client to access the vtkobject<BR>
transparently.<BR>
<BR>
> How do you create global ids while doing collaboration? Specifically, how<BR>
> do you ensure that two clients do not try to create the same global id?<BR>
<BR>
This is the plan: When a client connects to a server, it asks the<BR>
server for a "pool" of say 1000 global ids. The server reserves that<BR>
block of 1000 ids. When a second client connects, and asks for a<BR>
block, the server issues the next 1000 ids and reserves them and so<BR>
on. Now each client is free to use it's pool of reserved ids until<BR>
they are exhausted, when it goes back to the server and asks for more.<BR>
All this will be hidden in vtkProcessModule. So<BR>
vtkProcessModule::GetNextGID() (or whatever we call it) will always<BR>
returns a globally unique id. For course the id is valid only until<BR>
the server connection is valid. Once the client disconnects and<BR>
connects to a new server, the old proxies are marked "dead" and their<BR>
GID don't mean anything anymore.<BR>
<BR>
Utkarsh<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>