[Smtk-developers] Operator results with mesh changes

[David Thompson]

Hi TJ,

>> Because I would like to be able to perform existence/location tests on the client for CMB v4.
> 
> 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.
> 
> 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!

This helps, but it appears to have a missing piece or two. In particular,

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.

2. The "write mesh" operator does not update the collection's writeLocation. This is an easy fix:
--- a/smtk/io/WriteMesh.cxx
+++ b/smtk/io/WriteMesh.cxx
@@ -66,7 +66,12 @@ bool WriteMesh::operator()(
           format.Extensions.end())
       {
         // write the collection
-        return writer->write(filePath, collection, subset);
+        bool didWrite = writer->write(filePath, collection, subset);
+        if (didWrite)
+        {
+          collection->writeLocation(filePath);
+        }
+        return didWrite;
       }
     }
   }

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?

	David