[Paraview-developers] Plans for changes to ServerManger (Paraview 4.0 or later)

[Moreland, Kenneth]

Utkarsh,

I read through the document (thanks for going through that work).  Here are the rather random notes I took:


 *   One advantage I see of the new technique is in using a debugger.  Debugging is mentioned, but with respect to logging and tracing.  However, I'm more excited about being able to look at a snapshot in a debugger and trace back what client code instantiated it.  An additional feature could be a debug mode that "synchronized" the client and server.  That is, it makes the client wait until the server is finished processing each PushState or Invoke.
 *   I'm not entirely clear how the change encourages developers to use VTK objects directly.  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?  Do the original vtkSMProxy subclasses go away? (It sounds bad to have to pair them up.)
 *   If the vtkSMProxy classes get rearranged/deleted, how does that effect how the XML definitions are parsed?  Currently, there is some magic that takes XML tag names, mangles them into VTK class names, and instantiates a class of that name.  How will the new class hierarchy effect that?
 *   If the new implementation relies on Google protocol buffers, does that mean you need to install this in order to compile ParaView?  What happens if you want to compile ParaView for, say, the Cray XT or BlueGene?
 *   What is the granularity of the data pushes.  Is the state from multiple proxies pushed in the same message?  I would expect there to be too many messages otherwise.
 *   What is the role now of vtkSMProxy?  If all the logic is moving the the server side, does this class provide anything but a hollow wrapper around vtkSMRemoteObject?
 *   How do you create global ids while doing collaboration?  Specifically, how do you ensure that two clients do not try to create the same global id?

-Ken


On 7/13/10 4:49 PM, "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com> wrote:

Folks,

As some of you may be aware, we are working on bringing collaboration
support to ParaView enabling multiple ParaView clients to collaborate
with each other. To make it easier to keep ServerManager's among
clients synchronized as well as to reduce the client-server
communication in general, we are currently investigating restructuring
the internals for ServerManager -- mainly how proxies create VTK
objects an communicate with them. This wiki summarizes the proposed
design.

http://paraview.org/ParaView3/index.php/ServerManager_2.0

This generally won't affect developers writing custom applications or
plugins. However, we are planning on changing the
views/representations to move more logic to VTK-level as a part of
simplifying the client-side logic. So, expect some changes to how
views and representations are currently managed in ParaView. (This
document does not talk about those changes. We are currently playing
with some prototypes and once we have some better idea, we'll have
some things posted.)

These changes are still in early development stage. So changes in
ParaView proper are still a quarter or two away.

As always, any feedback is highly appreciated.

Utkarsh
_______________________________________________
Paraview-developers mailing list
Paraview-developers at paraview.org
http://public.kitware.com/mailman/listinfo/paraview-developers


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20100714/fd69b106/attachment.htm>