[Paraview-developers] Casual Weekend Read: ProcessModule 2.0

[Moreland, Kenneth]

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.

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 "http://hostname:port" 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.

-Ken


On 7/19/10 1: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.

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.

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?

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.


Pat

On Mon, Jul 19, 2010 at 1:50 PM, Utkarsh Ayachit <utkarsh.ayachit at kitware.com> wrote:
>> 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.
>
> Agreed.  (I was thinking something like ConnectionProtocol, but any name is
> equally bad.)  At any rate this should be its own class hierarchy and
> independent of ProcessModule, right?

Yes, and in that case, the vtkProcessModule::MonitorConnection()  will
move the this class as well.

Utkarsh
_______________________________________________
Paraview-developers mailing list
Paraview-developers at paraview.org
http://public.kitware.com/mailman/listinfo/paraview-developers


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20100719/f13d02fe/attachment.htm>