<HTML>
<HEAD>
<TITLE>Re: [Paraview-developers] Casual Weekend Read: ProcessModule 2.0</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>I was advocating that AcceptConnectionsOnPort would not be part of vtkProcessModule at all. Rather it would be encapsulated in its own class and specific things like port would be part of its state.<BR>
<BR>
If vtkProcessModule were to have a method like AcceptConnectionsOnPort, perhaps it could take a string that has a URL to the resources. Git-like URLs such as “<a href="http://hostname:port">http://hostname:port</a>” or “socket://hostname:port” or “ssl://username@hostname:port” would work. This method would return an abstract object (TransportManager/ConnectionProtocol) that could then manage the connection.<BR>
<BR>
-Ken<BR>
<BR>
<BR>
On 7/19/10 1:48 PM, "pat marion" <<a href="pat.marion@kitware.com">pat.marion@kitware.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>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>
On Mon, Jul 19, 2010 at 1:50 PM, Utkarsh Ayachit <<a href="utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>> wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>>> 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>
Yes, and in that case, the vtkProcessModule::MonitorConnection() will<BR>
move the this class as well.<BR>
<FONT COLOR="#888888"><BR>
Utkarsh<BR>
</FONT>_______________________________________________<BR>
Paraview-developers mailing list<BR>
<a href="Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><BR>
<a href="http://public.kitware.com/mailman/listinfo/paraview-developers">http://public.kitware.com/mailman/listinfo/paraview-developers</a><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>