[Smtk-developers] SMTK python script

[David Thompson]

Hi Yumin,

I'm including this on the devel list because... well, it's a shiny new mailing list. :-)

> ...
>>> I think an "import" operator may fit better here since we may need to handle other file formats that CMB used to load.
>> 
>> In terms of the SMTK API, I agree that it should be a separate operator. But from the application perspective, a user does not want importing a model to be a multistep operation where first an empty model of the proper type must be created before running the import operator on it. This is complicated by the fact that SMTK provides a list of file extensions that each modeling kernel+engine combination can read (using its "read" operator). How would we handle the file formats added by "import"?
> 
> Perfect timing for this discussion, because I am working on getting vtkCmbMoabReader (with CMake option to build or not) into smtk. I am planning to use the same pattern as the cgm bridge, ie, using the hand-edited Bridge_json.h to add file types supported by this reader (if it is built) to the discrete bridge, then ...
> 
>> I see 2 ways to go about it:
>> 1. Keep everything in the "read" operator but find a way to mark some file formats as native and others as "import" formats. The operator would then internally either read or import based on the format.
>> 
> I am leaning toward this approach, since 1. "import" still needs a "read" first, then 2. builds a cmbModel from its output, and finally 3. converts cmbModel to smtkModel. For a cmb file, we only need 1 and 3. Eventually (in the far far future), we could possibly make "import" skip 2 too by directly building an smtkModel from read's output. 
> 
> I am not sure what "mark file formats" as native and import will help, the read operator will still need separate logic to handle the "import" file formats like 2dm, 3dm, map, poly, vtk, exo, etc.

The benefit would be that users understand
1. They will not necessarily be able to save changes back in the original file format.
2. Not all of the features in the original file format are necessarily supported.

Also, it lets the application choose a better default kernel if one supports a format natively while another can only import the format.

>> 2. Add an "import" operator and include information about it in the Bridge's metadata. Then the application would know which bridge to create for the desired format and to use the "import" operator instead of "read".
>  
> This seems to move more logic to application.

Yes, but it makes an important distinction, plus it keeps the read operator smaller and more focused. It would not be a lot more code. The JSON for the bridge would change from something like:

{ "kernel": "cgm",
  "engines": [
    {
      "name": "ACIS",
      "filetypes": [
        ".iges (Initial Graphics Exchange Specification)",
        ".igs (Initial Graphics Exchange Specification)",
        ".sat (Standard ACIS Text)",
        ".sab (Standard ACIS Binary)"
      ]
    }, // ...
  ]
}

to

{ "kernel": "cgm",
  "engines": [
    {
      "name": "ACIS",
      "filetypes": [
        ".sat (Standard ACIS Text)",
        ".sab (Standard ACIS Binary)"
      ],
      "importformats": [
        ".iges (Initial Graphics Exchange Specification)",
        ".igs (Initial Graphics Exchange Specification)"
      ]
    }, // ...
  ]
}

We could just have BridgeRegistrar::bridgeFileTypes and BRepModel::bridgeFileTypes return StringData instead of a StringList (i.e., a map from string->vector<string> instead of a vector<string>) with "read" returning the list of kernel-native formats and "import" returning the list of files that can be read via the "import" operator. This also lets us deal with "write" and "export" down the road.

    What do you think?
    David