[Paraview] default_servers.pvsc question
Burlen Loring
burlen.loring at gmail.com
Wed Apr 15 12:34:35 EDT 2015
about (a): running multiple commands for each field could be annoying if
for ex one was trying to query a server side value and the user had to
enter their password more than once.
about (b), sounds OK but I'm not sure how it would work with the
connections to remote site.
in all this, I think we want to make the low-level (ie ssh tunnel)
connection once and make use of it from then on, for everything. as
opposed to making a connection for querying and then making another
connection for submitting/connecting to pvserver etc (or in your (a)
many connections).
In my suggestion of allowing a script(or as you "executable") to
generate the pvsc xml, PV can use a pipe to communicate to first fetch
the xml from the script then report the user selection back all while
keeping the script alive, and same connection open.
On 04/14/2015 02:00 PM, Utkarsh Ayachit wrote:
> Thanks Burlen/Rick.
>
> After discussing it with a few folks here, how about the following options:
>
> a. What if we make it possible to run an "executable" to obtain a
> value for any attribute in the XML. One could indeed use a Python
> script to produce that value or any other executable.
>
> b. We provide a mechanism to add a Python function in the PVSC. Before
> (and/or after) the PVSC is processed by the UI for display, it will
> pass the XML to that function which can update the XML as appropriate.
> This would mean that the Python code has to be aware of the PVSC's XML
> structure, but shouldn't be a problem since the Python code is
> embedded in the PVSC XML itself.
>
> Both will allow 1 and 2. 1 may still be a little hard work on the PVSC
> writer side, but it's a one time thing.
>
> Burlen, I think 3 is a little independent of this task. I do agree, we
> should embed all necessary tools in the paraview bundle -- something
> we've been talking about for a while. We should address that, I just
> don't want to commit to it just yet :).
>
> Thoughts? The more I think about it, I think I am leaning towards (b).
> For (a) the next logical question becomes how does one specify the
> path to the executable to run and we're back to the same problem we're
> trying to address :). What are your thoughts?
>
> Utkarsh
>
> On Mon, Apr 13, 2015 at 11:48 AM, Burlen Loring <burlen.loring at gmail.com> wrote:
>> OK, I added some notes based on the above discussion.
>>
>>
>> On 04/13/2015 08:33 AM, Utkarsh Ayachit wrote:
>>> Great, let's start here:
>>>
>>>
>>> https://docs.google.com/a/kitware.com/document/d/1uzi3VzpCxiGslhqaUde3ZbKcx-9LLG_ly3BYvDiPPx0/edit?usp=sharing
>>>
>>> Utkarsh
>>>
>>>
>>>
>>> On Mon, Apr 13, 2015 at 11:29 AM, Burlen Loring <burlen.loring at gmail.com>
>>> wrote:
>>>> Great, that sounds like a good way to start.
>>>>
>>>>
>>>> On 04/13/2015 06:53 AM, Utkarsh Ayachit wrote:
>>>>> Burlen/Rick,
>>>>>
>>>>> I am totally open to adding new features/refactoring the pvsc code.
>>>>> It hasn't changed much in a few years, and I am sure we know more than
>>>>> we did when we started with this :). Since you guys are the ones
>>>>> actually using this code in the field, it'd be great if you can
>>>>> identify the feature list of things missing or difficult to do in the
>>>>> current implementation and we can decide which would be best way
>>>>> forward.
>>>>>
>>>>> Should I create a google-doc or something which all can edit to built
>>>>> this
>>>>> list?
>>>>>
>>>>> Utkarsh
>>>>>
>>>>> On Mon, Apr 13, 2015 at 8:19 AM, Angelini, Richard C (Rick) CIV USARMY
>>>>> ARL (US) <richard.c.angelini.civ at mail.mil> wrote:
>>>>>> Burlen/Utkarsh —— my preferred solution is also to not set an
>>>>>> environment
>>>>>> variable if possible. For my particular issue, I’d much rather be able
>>>>>> to
>>>>>> do a `which ssh` (or equivalent) to get the answer than than asking the
>>>>>> user to set an environment variable.
>>>>>>
>>>>>> Implementing a python-based default_servers definition opens things up
>>>>>> for
>>>>>> much more programmatic flexibility.
>>>>>>
>>>>>> # take a guess at which ssh command to use
>>>>>>
>>>>>> try:
>>>>>> default_shell=os.popen("which ssh").read()
>>>>>> default_shell=default_shell.rstrip("\r\n")
>>>>>> except:
>>>>>> default_shell="/usr/krb5/bin/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ________________________________
>>>>>> Rick Angelini
>>>>>> USArmy Research Laboratory
>>>>>> CISD/HPC Architectures Team
>>>>>> Phone: 410-278-6266
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Burlen Loring <burlen.loring at gmail.com>
>>>>>> Date: Sunday, April 12, 2015 at 10:34 PM
>>>>>> To: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>, Rick Angelini
>>>>>> <Richard.C.Angelini.CIV at mail.mil>
>>>>>> Cc: "paraview at paraview.org" <paraview at paraview.org>
>>>>>> Subject: Re: [Paraview] default_servers.pvsc question
>>>>>>
>>>>>> Hi Utkarsh,
>>>>>>
>>>>>> I think environment variables are kind of a band aid around a larger
>>>>>> issue. In addition to leveraging the user's local environment, there's
>>>>>> also no way to get information from the server side environment. for
>>>>>> example list of account numbers a user can charge jobs to, or a list of
>>>>>> active queues. One thing I have been thinking about is rather than
>>>>>> just
>>>>>> reading pvsc from an xml file, paraview could call a script to get the
>>>>>> pvsc xml. This script could query the user's local/remote environment
>>>>>> and generate the xml. A long time ago we had talked about a python
>>>>>> based
>>>>>> solution. What do you think?
>>>>>>
>>>>>> Burlen
>>>>>>
>>>>>> On 4/12/2015 11:31 AM, Utkarsh Ayachit wrote:
>>>>>>> Rick,
>>>>>>>
>>>>>>> Alas no, this isn't currently supported. But should be fairly
>>>>>>> straightforward to add. I've reported a bug:
>>>>>>> http://www.paraview.org/Bug/view.php?id=15421
>>>>>>>
>>>>>>> Utkarsh
>>>>>>>
>>>>>>> On Fri, Apr 10, 2015 at 4:09 PM, Angelini, Richard C (Rick) CIV USARMY
>>>>>>> ARL (US) <richard.c.angelini.civ at mail.mil> wrote:
>>>>>>>> Question about the default_servers.pvsc file…..
>>>>>>>>
>>>>>>>> I have this in my host profile:
>>>>>>>>
>>>>>>>> <Server name=“My System" resource="csrc://127.0.0.1">
>>>>>>>> <CommandStartup>
>>>>>>>> <Options>
>>>>>>>> <Option name="SSHLOC" label="Local SSH Command" save="true">
>>>>>>>> <File default="/usr/local/bin/ssh"/>
>>>>>>>> </Option>
>>>>>>>>
>>>>>>>> So, when the GUI pops up, the user has an opportunity to change the
>>>>>>>> path to
>>>>>>>> ssh. But, rather than hard-coding the default value, or presenting
>>>>>>>> blank
>>>>>>>> field and have the user put in the correct path, is it possible to
>>>>>>>> query the
>>>>>>>> user’s environment and find `which ssh` and substitute in that
>>>>>>>> value??
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ________________________________
>>>>>>>> Rick Angelini
>>>>>>>> USArmy Research Laboratory
>>>>>>>> CISD/HPC Architectures Team
>>>>>>>> Phone: 410-278-6266
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>>
>>>>>>>> Search the list archives at: http://markmail.org/search/?q=ParaView
>>>>>>>>
>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>> http://public.kitware.com/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
>>>>>>>
>>>>>>> Search the list archives at: http://markmail.org/search/?q=ParaView
>>>>>>>
>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>> http://public.kitware.com/mailman/listinfo/paraview
>>>>>>
More information about the ParaView
mailing list