[Paraview-developers] Casual Weekend Read: ProcessModule 2.0

[Utkarsh Ayachit]

Pat,

On Mon, Jul 19, 2010 at 3:48 PM, pat marion <pat.marion at kitware.com> wrote:
> Currently vtkProcessModule forwards most of its work to
> vtkProcessModuleConnectionManager, so I assume when we discuss
> vtkProcessModule we mean vtkProcessModule +
> vtkProcessModuleConnectionManager.

Yes and no. ProcessModuleConnectionManager pretty much disappears.
Connection management related code moves to ProcessModule
(RegisterConnection etc.), while Connection setup related code moves
to a TransportManager.


> Toward the end, the wiki implies there will be new api for creating custom
> vtkConnection subclasses.  Sounds great!  So the earlier mentioned method
> AcceptConnectionsOnPort(int port) seems kind of underpowered.  The signature
> needs to be something like
>
> AcceptConnectionsOnPort(int port, ...)
>
> where "..." specifies a callback- or a factory- some logic to decide which
> vtkConnection subclass should be constructed to communicate on that port.
> Right now the connection type is hardcoded based on the process type.

Well, we'll move this to TransportManager, but even then, this doesn't
result in creation of a vtkConnection (or subclass), this is just a
transport level call to accept socket connections (for example), once
a connection is received, the TransportManager will fire an event
saying "A new client connected on port-id 12, here;s the socket to
talk with it". Let me add some more stuff to the Wiki explaining how a
vtkConnection will be created. That should make it easier to discuss
this.


> Are we going to continue having just one vtkClientServerInterpreter?  How to
> go about coordinating CS-IDs?  Previously you mentioned the idea of having
> each client request a batch of contiguous IDs from the server.  In the case
> of my coprocessor work, there are actually two servers- the coprocessor is
> equivalent to a symmetric pvbatch (where pvbatch is a client + builtin
> server), and it connects to a pvserver.  Some vtk objects exist on the
> coprocessor's builtin server, some vtk objects exist on the pvserver.  Will
> the new servermanager GUID scheme make this a non-issue?

GUID and CID together help unquiefy an ID. Remind me again, in your
case the client is not the one that's connecting to the "co-processor"
right? It's the pvserver that connects to the co-processor. Is that
correct?


> When a server has more than one client connection, GetLastResult breaks
> down.  Maybe it should be an atomic operation?  When you call SendStream you
> would specify whether or not you want to receive the result.

GetLastResult()/SendStream() no longer exist. All you have are atomic
PushState()/PullState() actions (refer to
http://paraview.org/ParaView3/index.php/ServerManager_2.0)

Utkarsh