[Paraview] Can a collaborative client share a pipeline without creating a view itself?

[Peter Debuchev]

Well, I see that I'll need some more debug sessions to get this solved.

>Why not make M aware of the code that needs to be executed and then
>just trigger those through higher level messages from S? This is like
>your first option, but you're only sending coarse messages eg. "Do
>Action1" etc to M.

Yes, this would be my option 2). "Make M aware of the code" means that I
need some interpreted language that I send from S to M. (I would probably
not use a separate message to execute the transmitted code, but rather
execute it as soon as it has completely arrived. But this is a minor
detail.)

What I don't understand is why only the master is allowed to add sources
etc. My attempts run fine if I start ParaView as master and then add
sources through my custom (slave) clients. Is the missing thread safety in
VTK the problem, so that I could run into synchronization issues if several
clients request changes on the server "at the same time"? (If so, I'd
suggest that the server rejects messages which are not originating from the
master.)

There is this one remaining problem that ParaView seems not to initialize
correctly if a different master has set up a pipeline earlier. Did you have
a chance to look into this issue? I might also file a bug report, if you
prefer.

Thanks
Peter


2016-06-20 16:03 GMT+02:00 Utkarsh Ayachit <utkarsh.ayachit at kitware.com>:

> Peter,
>
>
> > Or does additional
> > documentation (design documents, message exchange protocols, ...) exist?
>
> Sorry my friend. Nothing more than what I previously mentioned on the
> mailing list.
>
>
> http://www.paraview.org/ParaView/images/2/24/ParaViewCollaborationChanges.pdf
> http://www.paraview.org/ParaView/index.php/ProcessModule_2.0
> http://www.paraview.org/ParaView/index.php/ServerManager_2.0
>
>
> > So, although the concept of promoting different clients as master is
> obvious
> > from the video above, something more is needed to allow any slave to
> change
> > the pipeline automatically by permission of the master: the slave (S)
> must
> > request to be promoted as master to the current master (M), M must
> promote S
> > as master, S operates on the pipeline, and S must promote M as master
> again.
>
> (My knowledge on how several of these things is quite rusty  -- so
> bear with me). I'd suggest look at pqCollaborationManager and see how
> it implements chat messages. You should be able to extend that concept
> to add support for custom messages.
>
>
> > After some thoughts, my suggested option 2) may be easier and more
> secure: S
> > would send its intended operations to M, and M executes them. Here, the
> > question is whether I have to invent a new streaming language to encode
> > pipeline changes that S wants to send to M? Or can S just build the
> pipeline
> > as intended and use some available serialization to send this pipeline
> state
> > to M?
>
> Why not make M aware of the code that needs to be executed and then
> just trigger those through higher level messages from S? This is like
> your first option, but you're only sending coarse messages eg. "Do
> Action1" etc to M.
>
> > Any of the options requires some additional messages to be send between
> > slaves and master. This is what I am trying to figure out. The --cslog
> > options looks very useful, but a short overview which classes are
> involved
> > in sending custom messages including an encoded pipeline state would be
> even
> > more helpful.
>
> Follow the code path  from  pqCollaborationManager::onChatMessage().
> It calls pqServer::sendToOtherClients(...) with a vtkSMMessage object
> created.
>
> Utkarsh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20160620/9003411b/attachment.html>