<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'>Utkarsh,<BR>
<BR>
I read through the document (thanks for going through that work). &nbsp;Here are the rather random notes I took:<BR>
<BR>
</SPAN></FONT><UL><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>One advantage I see of the new technique is in using a debugger. &nbsp;Debugging is mentioned, but with respect to logging and tracing. &nbsp;However, I&#8217;m more excited about being able to look at a snapshot in a debugger and trace back what client code instantiated it. &nbsp;An additional feature could be a debug mode that &#8220;synchronized&#8221; the client and server. &nbsp;That is, it makes the client wait until the server is finished processing each PushState or Invoke.
</SPAN></FONT><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>I&#8217;m not entirely clear how the change encourages developers to use VTK objects directly. &nbsp;Is it because the code that is now in those many vtkSMProxy subclasses (e.g. the representations and views) moves to the server as vtkPVObject subclasses? &nbsp;Do the original vtkSMProxy subclasses go away? (It sounds bad to have to pair them up.)
</SPAN></FONT><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>If the vtkSMProxy classes get rearranged/deleted, how does that effect how the XML definitions are parsed? &nbsp;Currently, there is some magic that takes XML tag names, mangles them into VTK class names, and instantiates a class of that name. &nbsp;How will the new class hierarchy effect that?
</SPAN></FONT><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>If the new implementation relies on Google protocol buffers, does that mean you need to install this in order to compile ParaView? &nbsp;What happens if you want to compile ParaView for, say, the Cray XT or BlueGene?
</SPAN></FONT><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>What is the granularity of the data pushes. &nbsp;Is the state from multiple proxies pushed in the same message? &nbsp;I would expect there to be too many messages otherwise.
</SPAN></FONT><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>What is the role now of vtkSMProxy? &nbsp;If all the logic is moving the the server side, does this class provide anything but a hollow wrapper around vtkSMRemoteObject?
</SPAN></FONT><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>How do you create global ids while doing collaboration? &nbsp;Specifically, how do you ensure that two clients do not try to create the same global id?<BR>
</SPAN></FONT></UL><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
-Ken<BR>
<BR>
<BR>
On 7/13/10 4:49 PM, &quot;Utkarsh Ayachit&quot; &lt;<a href="utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Folks,<BR>
<BR>
As some of you may be aware, we are working on bringing collaboration<BR>
support to ParaView enabling multiple ParaView clients to collaborate<BR>
with each other. To make it easier to keep ServerManager's among<BR>
clients synchronized as well as to reduce the client-server<BR>
communication in general, we are currently investigating restructuring<BR>
the internals for ServerManager -- mainly how proxies create VTK<BR>
objects an communicate with them. This wiki summarizes the proposed<BR>
design.<BR>
<BR>
<a href="http://paraview.org/ParaView3/index.php/ServerManager_2.0">http://paraview.org/ParaView3/index.php/ServerManager_2.0</a><BR>
<BR>
This generally won't affect developers writing custom applications or<BR>
plugins. However, we are planning on changing the<BR>
views/representations to move more logic to VTK-level as a part of<BR>
simplifying the client-side logic. So, expect some changes to how<BR>
views and representations are currently managed in ParaView. (This<BR>
document does not talk about those changes. We are currently playing<BR>
with some prototypes and once we have some better idea, we'll have<BR>
some things posted.)<BR>
<BR>
These changes are still in early development stage. So changes in<BR>
ParaView proper are still a quarter or two away.<BR>
<BR>
As always, any feedback is highly appreciated.<BR>
<BR>
Utkarsh<BR>
_______________________________________________<BR>
Paraview-developers mailing list<BR>
<a href="Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><BR>
<a href="http://public.kitware.com/mailman/listinfo/paraview-developers">http://public.kitware.com/mailman/listinfo/paraview-developers</a><BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>