[Paraview-developers] Casual Weekend Read: ProcessModule 2.0

[Utkarsh Ayachit]

I agree with Ken, "AcceptConnectionOnPort" moves to the
TransportManager (or whatever we call it). ProcessModule remains
agnostic of that. I like Ken's other suggestion as well (with the
urls). For starters, we can just leave it out. But add that API to
ProcessModule as and when needed in future.

Utkarsh


On Mon, Jul 19, 2010 at 4:21 PM, Moreland, Kenneth <kmorel at sandia.gov> wrote:
> 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
>
>
>