Does this request have anything to do with remote file systems using ICEResource#getName() and local file systems using ICEResource#getPath()#getPath() as the input parameter of ViewerMethods#openDatabase(String)? Are there any other proposed updates? Could the updates be addressed by modifying the VizResource? Matt wrote that class to extend ICEResource and address some unique features of the .csv plotting tool. Can that class be further modified to address the updates required here?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed this change in the NiCE client to load the remote file with the
AddRemoteAction, which is cool.
Unfortunately, the code still assigned it to ICEResource which doesn't tell
the other pieces of code whether the ICEResource is from a local file or
remote one. The remote OpenDatabase call doesn't understand getPath() from
a local directory as it doesn't exist on the temote file system.
I have a solution already implemented in a new branch for the resource, but
the design requires further discussion.
The variables for instance need to be aware of what machine they belong to.
For example, the VisItPlotViewer's treeview only tracks the name and type,
but doesn't track the source machine. So, it is hard to tell whether a
rendering canvas whether it can actually render that variable. It would be
great if we could filter variables before trying to load it into the canvas
I can elaborate further tomorrow.
Best regards,
Hari
On Aug 13, 2014 9:34 AM, "Taylor Patterson" tcpatt@users.sf.net wrote:
Does this request have anything to do with remote file systems using
ICEResource#getName() and local file systems using
ICEResource#getPath()#getPath() as the input parameter of
ViewerMethods#openDatabase(String)? Are there any other proposed updates?
Could the updates be addressed by modifying the VizResource? Matt wrote
that class to extend ICEResource and address some unique features of the
.csv plotting tool. Can that class be further modified to address the
updates required here?
Status: open Group: Next Release (example) Created: Thu Jul 31, 2014 08:21 PM UTC by Hari Krishnan Last Updated: Thu Jul 31, 2014 08:21 PM UTC Owner: Jay Jay Billings
Update ICEResource to handle files residing on remote machines.
You guys should try to use URIs.
On Aug 13, 2014 1:34 PM, "Hari Krishnan" harikrishnan79@users.sf.net
wrote:
I noticed this change in the NiCE client to load the remote file with the
AddRemoteAction, which is cool.
Unfortunately, the code still assigned it to ICEResource which doesn't tell
the other pieces of code whether the ICEResource is from a local file or
remote one. The remote OpenDatabase call doesn't understand getPath() from
a local directory as it doesn't exist on the temote file system.
I have a solution already implemented in a new branch for the resource, but
the design requires further discussion.
The variables for instance need to be aware of what machine they belong to.
For example, the VisItPlotViewer's treeview only tracks the name and type,
but doesn't track the source machine. So, it is hard to tell whether a
rendering canvas whether it can actually render that variable. It would be
great if we could filter variables before trying to load it into the canvas
I can elaborate further tomorrow.
Best regards,
Hari
On Aug 13, 2014 9:34 AM, "Taylor Patterson" tcpatt@users.sf.net wrote:
Does this request have anything to do with remote file systems using
ICEResource#getName() and local file systems using
ICEResource#getPath()#getPath() as the input parameter of
ViewerMethods#openDatabase(String)? Are there any other proposed updates?
Could the updates be addressed by modifying the VizResource? Matt wrote
that class to extend ICEResource and address some unique features of the
.csv plotting tool. Can that class be further modified to address the
updates required here?
Status: open Group: Next Release (example) Created: Thu Jul 31, 2014 08:21 PM UTC by Hari Krishnan Last Updated: Thu Jul 31, 2014 08:21 PM UTC Owner: Jay Jay Billings
Update ICEResource to handle files residing on remote machines.
Status: open Group: Next Release (example) Created: Thu Jul 31, 2014 08:21 PM UTC by Hari Krishnan Last Updated: Wed Aug 13, 2014 04:34 PM UTC Owner: Jay Jay Billings
Update ICEResource to handle files residing on remote machines.
Also, the fileviewer might need to track which connections belong to which
file.
As that information is also being lost in the current design.
Best regards,
Hari
On Aug 13, 2014 9:59 AM, "Harinarayan Krishnan" hkrishnan@lbl.gov wrote:
I noticed this change in the NiCE client to load the remote file with the
AddRemoteAction, which is cool.
Unfortunately, the code still assigned it to ICEResource which doesn't
tell the other pieces of code whether the ICEResource is from a local file
or remote one. The remote OpenDatabase call doesn't understand getPath()
from a local directory as it doesn't exist on the temote file system.
I have a solution already implemented in a new branch for the resource,
but the design requires further discussion.
The variables for instance need to be aware of what machine they belong
to. For example, the VisItPlotViewer's treeview only tracks the name and
type, but doesn't track the source machine. So, it is hard to tell whether
a rendering canvas whether it can actually render that variable. It would
be great if we could filter variables before trying to load it into the
canvas
I can elaborate further tomorrow.
Best regards,
Hari
On Aug 13, 2014 9:34 AM, "Taylor Patterson" tcpatt@users.sf.net wrote:
Does this request have anything to do with remote file systems using
ICEResource#getName() and local file systems using
ICEResource#getPath()#getPath() as the input parameter of
ViewerMethods#openDatabase(String)? Are there any other proposed updates?
Could the updates be addressed by modifying the VizResource? Matt wrote
that class to extend ICEResource and address some unique features of the
.csv plotting tool. Can that class be further modified to address the
updates required here?
Status: open Group: Next Release (example) Created: Thu Jul 31, 2014 08:21 PM UTC by Hari Krishnan Last Updated: Thu Jul 31, 2014 08:21 PM UTC Owner: Jay Jay Billings
Update ICEResource to handle files residing on remote machines.
Those are some additional considerations that I hadn't thought of previously. My initial thought was that VizResource could just have an isRemote flag, but that clearly won't address the issue of keeping track of the machine where the files reside. Perhaps the VizResource can still be modified to address this need while also cleaning up some code elsewhere in the viz bundle. Hari, is your proposed solution in ICEResource in your branch? If so, I'll check that out and try to integrate that into the subclass (VizResource).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My solution subclasses the ICEResource. The subclass (RemoteICEResource)
stores the additional information needed to determine the source. I am fine
with using a URI scheme to store the additional details.
Best regards,
Hari
On Aug 13, 2014 10:56 AM, "Taylor Patterson" tcpatt@users.sf.net wrote:
Those are some additional considerations that I hadn't thought of
previously. My initial thought was that VizResource could just have an
isRemote flag, but that clearly won't address the issue of keeping track of
the machine where the files reside. Perhaps the VizResource can still be
modified to address this need while also cleaning up some code elsewhere in
the viz bundle. Hari, is your proposed solution in ICEResource in your
branch? If so, I'll check that out and try to integrate that into the
subclass (VizResource).
Status: open Group: Next Release (example) Created: Thu Jul 31, 2014 08:21 PM UTC by Hari Krishnan Last Updated: Wed Aug 13, 2014 04:34 PM UTC Owner: Jay Jay Billings
Update ICEResource to handle files residing on remote machines.
Status: open Group: Next Release (example) Created: Thu Jul 31, 2014 08:21 PM UTC by Hari Krishnan Last Updated: Wed Aug 13, 2014 04:34 PM UTC Owner: Jay Jay Billings
Update ICEResource to handle files residing on remote machines.
We can't really change ICEResource because it is used in so many places. A
subclass is the best way to handle it.
On Aug 13, 2014 12:34 PM, "Taylor Patterson" tcpatt@users.sf.net wrote:
Does this request have anything to do with remote file systems using
ICEResource#getName() and local file systems using
ICEResource#getPath()#getPath() as the input parameter of
ViewerMethods#openDatabase(String)? Are there any other proposed updates?
Could the updates be addressed by modifying the VizResource? Matt wrote
that class to extend ICEResource and address some unique features of the
.csv plotting tool. Can that class be further modified to address the
updates required here?
Status: open Group: Next Release (example) Created: Thu Jul 31, 2014 08:21 PM UTC by Hari Krishnan Last Updated: Thu Jul 31, 2014 08:21 PM UTC Owner: Jay Jay Billings
Update ICEResource to handle files residing on remote machines.
Does this request have anything to do with remote file systems using ICEResource#getName() and local file systems using ICEResource#getPath()#getPath() as the input parameter of ViewerMethods#openDatabase(String)? Are there any other proposed updates? Could the updates be addressed by modifying the VizResource? Matt wrote that class to extend ICEResource and address some unique features of the .csv plotting tool. Can that class be further modified to address the updates required here?
I noticed this change in the NiCE client to load the remote file with the
AddRemoteAction, which is cool.
Unfortunately, the code still assigned it to ICEResource which doesn't tell
the other pieces of code whether the ICEResource is from a local file or
remote one. The remote OpenDatabase call doesn't understand getPath() from
a local directory as it doesn't exist on the temote file system.
I have a solution already implemented in a new branch for the resource, but
the design requires further discussion.
The variables for instance need to be aware of what machine they belong to.
For example, the VisItPlotViewer's treeview only tracks the name and type,
but doesn't track the source machine. So, it is hard to tell whether a
rendering canvas whether it can actually render that variable. It would be
great if we could filter variables before trying to load it into the canvas
I can elaborate further tomorrow.
Best regards,
Hari
On Aug 13, 2014 9:34 AM, "Taylor Patterson" tcpatt@users.sf.net wrote:
Related
Feature Requests: #16
You guys should try to use URIs.
On Aug 13, 2014 1:34 PM, "Hari Krishnan" harikrishnan79@users.sf.net
wrote:
Related
Feature Requests: #16
Also, the fileviewer might need to track which connections belong to which
file.
As that information is also being lost in the current design.
Best regards,
Hari
On Aug 13, 2014 9:59 AM, "Harinarayan Krishnan" hkrishnan@lbl.gov wrote:
Related
Feature Requests: #16
Those are some additional considerations that I hadn't thought of previously. My initial thought was that VizResource could just have an isRemote flag, but that clearly won't address the issue of keeping track of the machine where the files reside. Perhaps the VizResource can still be modified to address this need while also cleaning up some code elsewhere in the viz bundle. Hari, is your proposed solution in ICEResource in your branch? If so, I'll check that out and try to integrate that into the subclass (VizResource).
My solution subclasses the ICEResource. The subclass (RemoteICEResource)
stores the additional information needed to determine the source. I am fine
with using a URI scheme to store the additional details.
Best regards,
Hari
On Aug 13, 2014 10:56 AM, "Taylor Patterson" tcpatt@users.sf.net wrote:
Related
Feature Requests: #16
Have you committed RemoteICEResource to the repo somewhere?
No. Unfortunately, It is part of the other set of changes I have for the
NiCE client.
Best regards,
Hari
On Aug 13, 2014 11:37 AM, "Taylor Patterson" tcpatt@users.sf.net wrote:
Related
Feature Requests: #16
I think so.
We can't really change ICEResource because it is used in so many places. A
subclass is the best way to handle it.
On Aug 13, 2014 12:34 PM, "Taylor Patterson" tcpatt@users.sf.net wrote:
Related
Feature Requests: #16