[Paraview-developers] Casual Weekend Read: ProcessModule 2.0

[pat marion]

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/223c157a/attachment.htm>