<div dir="ltr">Looks like you posted while I was writing my post.<div><br></div><div>1. Yes this is desired as the results of a mesh operation are really temporary, and currently use a temporary file since Remus has been updated to do automatic file transportation. With the locations currently being inside a system temporary directory, they should never be considered to be valid files for long term purposes. If we ever cycle back to remote mesh operators, this system will have to overhauled, and very possibly the results of the mesh operator will never have a file backing.</div><div><br></div><div>2. I haven't did a deep look into WriteMesh, but we need to confirm that we have a clear understanding of Export, Write, and WriteAs handled properly. I am concerned that saving the location to writeLocation could change a subsequent model write  in the future by mistake.</div><div><br></div><div>Now if these changes are correct, you should specify the writeLocation before calling write, as that will allow you to us the unspecified writer->write api IIRC.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 9:34 AM, David Thompson <span dir="ltr"><<a href="mailto:david.thompson@kitware.com" target="_blank">david.thompson@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi TJ,<br>
<span class=""><br>
>> Because I would like to be able to perform existence/location tests on the client for CMB v4.<br>
><br>
> Ah, that’s a very good reason! I’ve cc’d Robert because he’s the guy to ask, but I can give you my version of an answer.<br>
><br>
> smtk::mesh currently supports two “interfaces”: Moab and Json. The Moab interface is the one that runs on the server, has the database, and does all of the actual work. The Json interface runs on the client, and it nulls out the database calls and only carries metainformation about mesh collections, mesh sets, etc. It looks as though these two are kept in sync somewhere in SaveJson, but the code is rather squirrely (maybe try SaveJSON::forManagerMeshes? The mesh info gets updated if JSON_MESHES is one of the flags passed to SaveJSON::forManager). Hope this helps!<br>
<br>
</span>This helps, but it appears to have a missing piece or two. In particular,<br>
<br>
1. The "mesh" operator itself always clears the read+write locations (so that, according to comments, it appears that the mesh has not been saved by the mesh worker but is instead an in-server-memory-only mesh), so the JSON mesh interface on the client initially has no location information. This is kinda clunky since the mesh must be rewritten, but OK. At least it appears that the result-attribute of this operation includes the "mesh_created" item so the client knows to ask for an update of the JSON interface.<br>
<br>
2. The "write mesh" operator does not update the collection's writeLocation. This is an easy fix:<br>
--- a/smtk/io/WriteMesh.cxx<br>
+++ b/smtk/io/WriteMesh.cxx<br>
@@ -66,7 +66,12 @@ bool WriteMesh::operator()(<br>
           format.Extensions.end())<br>
       {<br>
         // write the collection<br>
-        return writer->write(filePath, collection, subset);<br>
+        bool didWrite = writer->write(filePath, collection, subset);<br>
+        if (didWrite)<br>
+        {<br>
+          collection->writeLocation(<wbr>filePath);<br>
+        }<br>
+        return didWrite;<br>
       }<br>
     }<br>
   }<br>
<br>
3. The "write mesh" operator does not contain any items in the result attribute indicating what collections were actually written to disk, so there is no way to know what meshes need to be written. While it looks like the "mesh_modified" item exists for this purpose (SaveJSON::forOperatorResult() adds the JSON metadata when it is present), the "mesh_modified" item is expected to be an instance of smtk::attribute::MeshItem, which holds MeshSets not Collections. Are we intended to use this by creating empty meshsets whose parent is the collection with the modified URL?<br>
<span class="HOEnZb"><font color="#888888"><br>
        David</font></span></blockquote></div><br></div>