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

[Utkarsh Ayachit]

I couldn't agree more. The whole "move-to-vtk" drive will hopefully
make xml simpler and pipelines easier to follow.

Utkarsh

On Wed, Jul 14, 2010 at 3:59 PM, Moreland, Kenneth <kmorel at sandia.gov> wrote:
> 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
>
>
>