[Paraview] Paraview 3.6.x connection definition files
Utkarsh Ayachit
utkarsh.ayachit at kitware.com
Fri Oct 30 08:01:04 EDT 2009
That's interesting. Let me take a look at this. The goal of
default_servers.pvsc was indeed to support the use-case as you
describe, where the site-administrator can change the configuration
file and all the "users" get the updated configuration. Since this
code passed through many hands, there may have been some confusion
with this. I'll keep you posted.
Utkarsh
On Fri, Oct 23, 2009 at 12:55 PM, Rick Angelini <angel at arl.army.mil> wrote:
> I have questions regarding the use of connection definition files.
> I have created numerous connection definition files for various clusters and
> compute systems that we have here. Up until now, I've been distributing
> those pvsc files through a common directory that all of my users have access
> to. They manually load the pvsc files into their session, and those server
> definitions get automatically saved into
> $HOME/.config/ParaView/servers.pvsc. The connection definition files
> work great and are a huge time saver for Paraview users - particularly in an
> environment where we need to establish SSH tunnels, modify ports and
> connection IDs, etc.
>
> The problem lies in what happens when I want to change one or more of those
> pvsc files (presumably to incorporate a change that will improve
> functionality, performance, etc 8-) I update the pvsc file in the common
> directory, and then I need to notify all of my Paraview users that there's
> an update to the PVSC files and that they need to delete/replace their
> existing definition with a new one. This scenario is awkward and requires
> some effort on the users' part - it would be nice if there were a more
> automatic solution.
>
> So, I've been looking at using a default_servers.pvsc file which in theory
> is a great idea. All users would have access to a common pvsc file that I
> can control and update as necessary, with no updates required by the user.
> Well, unfortunately, it doesn't seem to really work that way. The
> default_servers.pvsc file is read in the first time ParaView is loaded, and
> then those server definitions are saved back to the $HOME/.config/ParaView
> directory. The servers are presumably saved off to preserve some of the
> information as defined in the PVSC file - I have numerous fields (UserID,
> ProjectID, SSH executable labeled with "save=true" so that that information
> is carried over between sessions.
>
> This is where we start to run into problems. According to the WIKI, the
> last server definition loaded take precedence, so if I make changes to the
> "default_servers.pvsc" file, it gets loaded prior to
> "$HOME/.config/ParaView/servers.pvsc". Unless I'm missing something,
> once the server definitions are initialized the first time they are
> recognized and saved off to the user's .config directory, the default
> servers will never have precedence, even if I change/update the contents.
> Unless the ServerName is changed for each subsequent update of a particular
> server, any updated server in the default servers file won't be loaded.
> Am I on the right track here - have I missed or assumed something that I
> shouldn't have? It looks like all of the hooks are *almost* there to
> manage the server definitions .....
>
> Also, using 3.6.1, I went through the process of created a
> default_servers.pvsc, having those servers automatically loaded in my
> ParaView session, and then have them saved off into a local servers.pvsc
> file. However, during the next Paraview session, the definitions don't work
> properly - it seems as those the only the last item in an enumerated list
> are available through the GUI, and in general it just doesn't work
> correctly. If those same server definitions are loaded manually by the
> user and saved locally, they work fine. So, there's apparently an issue
> related to the use of the default_servers.pvsc and how those definitions are
> saved out to the user's server.pvsc file.
>
>
> _______________________________________________
> 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
>
More information about the ParaView
mailing list