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

[Moreland, Kenneth]

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.

-Ken


On 7/14/10 2:58 PM, "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com> wrote:

Ken,

> 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.

Great idea. I've added that to the Wiki page so we can keep it in mind
as we implement it.

> 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.)

As a simple solution, yes, all code in vtkSMProxy subclasses can move
to vtkPVObject subclasses. But a cleaner solution would be move that
code to a vtkObject subclass instead and then simply use that. Having
a large number of vtkSMProxy subclasses like we currently do is
turning out to be a nightmare. When a large number of sub-proxies are
involved (look at representations/views) the code in inevitably
unreadable. All those can be rewritten as vtk-level code directly in
most cases. I am currently working on vtkPVRenderView that is a
vtkView subclass with all client-server/parallel communication
encapsulated with no major need for special code in vtkSMProxy. We can
very well design almost all other vtkSMPRoxy subclasses that way.
Ideally, you are correct, all vtkSMProxy subclasses should just go
away (except may be vtkSMSourceProxy).

> 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?

Definitions will have to change to reflect the new class name to
create. So for a view, if we get rid of vtkSMViewProxy, the XML
definition unfortunately will have to change to use just <Proxy />
instead of <ViewProxy />. To tell what PM object to create for that
proxy, we can add a new optional attribute something like
pmobject="vtkPMViewProxy".

> 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?

 We have a cmakified version of protobuf. Protobuf does not have many
external dependencies so don't see any reason why it won't compile on
a machine where ParaView compiles. Since protobuf is BSD, we will
include it as under ParaView/Utilities itself so users don't have to
install/build is separately.

> 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.

Every time a vtkSMProxy::UpdateVTKObjects() gets called, it will try
to push its state for all the modified properties. All PushState()
calls are routed through the ProcessModule. The ProcessModule can
buffer these PushState() calls until buffer fills up or Flush() or
PullState() or GatherInformation() happens. Since there's no arbitrary
GetLastResult() or such call on ProcesModule anymore, such buffering
is feasible. Even without buffering, however, this won't be any worse
than what currently happens in ServerManager.

> 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?

vtkSMProxy is client-side state holder for the vtkObject. We are
moving the VTKObject updating logic out from vtkSMPRoxy. It still
provides the facade to the client to access the vtkobject
transparently.

> 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?

This is the plan: When a client connects to a server, it asks the
server for a "pool" of say 1000 global ids. The server reserves that
block of 1000 ids. When a second client connects, and asks for a
block, the server issues the next 1000 ids and reserves them and so
on. Now each client is free to use it's pool of reserved ids until
they are exhausted, when it goes back to the server and asks for more.
All this will be hidden in vtkProcessModule. So
vtkProcessModule::GetNextGID() (or whatever we call it) will always
returns a globally unique id. For course the id is valid only until
the server connection is valid. Once the client disconnects and
connects to a new server, the old proxies are marked "dead" and their
GID don't mean anything anymore.

Utkarsh


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