[Paraview-developers] Casual Weekend Read: ProcessModule 2.0

[Utkarsh Ayachit]

> Why does vtkProcessModule have to init functions that must be call
> sequentially?  Why not just have one initialization function?

Good point. The only reason why that seemed necessary was that the
command line argument needed to be passed to MPI_Init() before they
can be passed to vtkPVOptions for parsing during initialization. And
to keep things clear, we were saying a vtkProcessModule will always
have a initialized vtkPVOptions instance. This was essential in the
past since the ProcessModule in its initialization needed to know what
server-port to wait on etc. But now since that's not the case,
ProcessModule does not need vtkPVOptions for initialization, in which
case we can indeed merge the two inits calls into one.

> Can the client call AcceptConnectionsOnPort?  Is that for reverse
> connections?  The documentation that this class is to establish a service.

Yes, client will use AcceptConnectionsOnPort for reverse connection.

> The connections methods talk about sockets & TCP/IP.  What about other
> connection types like SSL, HTTPS, MPI, or Portals.  They come up.

Actually I hadn't thought of this. Maybe abstracting all transport in
a TransportManager or something that can be swapped with
implementations for different transports maybe a possibility.

MPI? For client-server? I am not sure what you mean. The MPI for
root-satellite communication will be managed by
vtkProcessModuleConnection itself.

> How does vtkConnection establish itself with a socket connection managed by
> the vtkProcessModule?

vtkConnection::Create() will do calls like AcceptConnectionsOnPort
during its intiialization and then add observers to the process module
to know when a new connection is received on  that server-socket. Once
a connection is received, it will grab it and possible assign it a
role eg. data-server socket/render-server socket etc. Once a
connection has a received all connections it needs it will go ahead a
register itself with the ProcessModule. That's when it becomes a
"known" connection.

> I find logging a bit overrated.  I find I would usually rather have
> synchronous client/server communication where if the server is stopped the
> client blocks on the last call that initiated the server.

I've used logging a great deal, esp. initially when I was learning
what exactly was happening in the streams. But yea, providing an
option for synchronized runs also makes sense and surely would be
useful for debugging.

Utkarsh