Currently vtkProcessModule forwards most of its work to vtkProcessModuleConnectionManager, so I assume when we discuss vtkProcessModule we mean vtkProcessModule + vtkProcessModuleConnectionManager.<br><br>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<br>
<br>AcceptConnectionsOnPort(int port, ...)<br><br>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.<br>
<br>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?<br>
<br>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.<br><br>
<br>Pat<br><br><div class="gmail_quote">On Mon, Jul 19, 2010 at 1:50 PM, Utkarsh Ayachit <span dir="ltr"><<a href="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">>> Actually I hadn't thought of this. Maybe abstracting all transport in<br>
>> a TransportManager or something that can be swapped with<br>
>> implementations for different transports maybe a possibility.<br>
><br>
> Agreed. (I was thinking something like ConnectionProtocol, but any name is<br>
> equally bad.) At any rate this should be its own class hierarchy and<br>
> independent of ProcessModule, right?<br>
<br>
</div>Yes, and in that case, the vtkProcessModule::MonitorConnection() will<br>
move the this class as well.<br>
<font color="#888888"><br>
Utkarsh<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Paraview-developers mailing list<br>
<a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
<a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
</div></div></blockquote></div><br>