[Paraview-developers] Casual Weekend Read: ProcessModule 2.0

[Utkarsh Ayachit]

Ken/Pat,

I've updated the Wiki. To make the distinction between a raw
connection between processes and a connection between server procs and
client, I am using the terms vtkNetworkConnection and vtkSession.

http://paraview.org/ParaView3/index.php?title=ProcessModule_2.0

Utkarsh

On Mon, Jul 19, 2010 at 5:28 PM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> 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
>