[Paraview] Distributing PVSC files (ParaView 4.0)

[Tim Gallagher]

I know for our HPC access, they require a custom version of SSH that has been security enhanced. So if PV used a built-in libssh, we would be unable to use PV to connect through to them.

I don't have a better solution, just wanted to point out that packaging libssh without an option to use a system one would not work in some cases.

Tim

----- Original Message -----
From: "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com>
To: "Burlen Loring" <bloring at lbl.gov>
Cc: "ParaView" <paraview at paraview.org>
Sent: Tuesday, August 23, 2011 9:38:38 AM
Subject: Re: [Paraview] Distributing PVSC files (ParaView 4.0)

Burlen,

Good points. At the risk of stating the obvious let's note that we'll
be able to distribute different pvsc versions for the server for
different OSs and ParaView versions without any issue. Now locating
ssh/xterm/plink etc are indeed real issues.

I don't like the cmake approach, it requires that we need a separate
step and would require users to install cmake (unless we include cmake
in the binaries). libssh approach sounds interesting. The only concern
is will users to reluctant to use a ssh client we provide rather than
their chosen (and trusted one).

Like John said, the file inputs are already supported in pvsc.

Pat Marion has been pushing for the ability to have Python scripts
instead-of/in-addition-to pvsc-xmls. I think that's another viable
approach since it allows us to write code to discover information
about the client/server and take appropriate action(s).

Utkarsh

On Mon, Aug 22, 2011 at 12:34 PM, Burlen Loring <bloring at lbl.gov> wrote:
> Hi Utkarsh,
>
> this looks great.
>
> One thing I have encountered and that you may want to think about is that a
> single static pvsc is not going to work for all users as pvsc's depend on
> external components such as xterm, ssh, and plink. These are in different
> places on different user's systems, maybe not present on the user's system
> leading to the pvsc not working.
>
> I could see a couple of different avenues to solve this: Probably the best
> would be to integrate ssh tunneling into PV via libssh so that these
> dependencies are not needed. An aleternative would be to include a configure
> step in your new pvsc import process (like cmake) where dependencies are
> located and a system specific pvcs is generated. Something far easier and
> less intrusive might be to add a file dialog element to the pvsc syntax so
> that the user could easily  browse for these files. That's not as nice as
> the other approaches because it clutters the UI and the user still has to
> hunt down the files, but it at least gives them a method to do so.
>
> Burlen
>
> On 08/19/2011 02:15 PM, Utkarsh Ayachit wrote:
>>
>> Folks,
>>
>> A feature we are thinking of implementing for ParaView 4.0 is to make
>> it easier to distribute pvsc files to connect to various HPC
>> resources. I've sketched out a rough proposal for the same at
>>
>> http://paraview.org/ParaView3/index.php/Distributing_Server_Configuration_Scripts
>>
>> Any comments/suggestions are always welcome.
>>
>> Utkarsh
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ParaView Wiki at:
>> http://paraview.org/Wiki/ParaView
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.paraview.org/mailman/listinfo/paraview
>
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview