New requirements proposed for iMeshP: bootcamp discussion
Attached is a write-up of the "compromise" solution I promised after our discussion at bootcamp. I'm sorry it is late; I wrote it last week but forgot to mail it out. Please read and consider it; then reply with your thoughts. Thanks! Karen
Karen, What you wrote brought up a question here that we haven't been able to answer cleanly. It's a pretty basic question that probably should have come up before, but it's possible that we have been assuming things based how we have interpreted what we have read, so here's the question: What are the definitions of "mesh instance" and "mesh" for iMesh? More specifically, I can infer what the definition of a "mesh instance" is from the API and other documentation (although I think a precise definition would be nice), but it's not clear what the definition of a "mesh" is supposed to be. Also, as a side question related to function naming, why is the function that creates a mesh instance named iMesh_newMesh? mark
In a nutshell, we decided that a "mesh instance" is in effect a "mesh database" that may contain one or more actual meshes. As such, it makes most sense to have one database per implementation per process. I apologize for not reviewing the mailing list and my notes before the bootcamp.
[Off on a tangent: A comment was made in the thread that the name "mesh instance" is confusing, as it implies an instantiation of a single mesh, and I still agree with that comment, preferring "mesh database." But we are NOT arguing this point here, and I am NOT proposing to change the name, so do NOT reply about this short vent. There will be plenty more to reply about below. :)]
On May 4, 2010, at 11:07 AM, Devine, Karen D wrote:
Attached is a write-up of the "compromise" solution I promised after our discussion at bootcamp. I'm sorry it is late; I wrote it last week but forgot to mail it out.
Please read and consider it; then reply with your thoughts. Thanks!
Karen
<compromise.txt>
Hi, Mark B. After much education from the TSTT team, I learned that a "mesh instance" is a database containing entities, adjacency info, sets, and tags. It manages all that stuff and answers queries about it. A "mesh" is not really an ITAPS data type. It is a concept defined by the application. The ITAPS "mesh instance" is organized only in terms of sets of entities. If the application considers a particular set of entities to be a "mesh," that's great. If an application wants to consider two "meshes," it can load them into the same database and store them in separate entity sets. So the short answer in the way I think about it is as follows: A "mesh instance" is a database. A "mesh" is an entity set in the database that the application interprets in a particular way. Your question is timely. There is a discussion going on right now on the tstt-interfaces mailing list about function names, including iMesh_newMesh. In truth, it should be iMesh_newMeshInstance (or, as the discussion is leading toward using "create" instead of "new", iMesh_createMeshInstance). Karen On 5/7/10 10:43 AM, "Mark Beall" <[email protected]> wrote:
Karen,
What you wrote brought up a question here that we haven't been able to answer cleanly. It's a pretty basic question that probably should have come up before, but it's possible that we have been assuming things based how we have interpreted what we have read, so here's the question:
What are the definitions of "mesh instance" and "mesh" for iMesh? More specifically, I can infer what the definition of a "mesh instance" is from the API and other documentation (although I think a precise definition would be nice), but it's not clear what the definition of a "mesh" is supposed to be.
Also, as a side question related to function naming, why is the function that creates a mesh instance named iMesh_newMesh?
mark
In a nutshell, we decided that a "mesh instance" is in effect a "mesh database" that may contain one or more actual meshes. As such, it makes most sense to have one database per implementation per process. I apologize for not reviewing the mailing list and my notes before the bootcamp.
[Off on a tangent: A comment was made in the thread that the name "mesh instance" is confusing, as it implies an instantiation of a single mesh, and I still agree with that comment, preferring "mesh database." But we are NOT arguing this point here, and I am NOT proposing to change the name, so do NOT reply about this short vent. There will be plenty more to reply about below. :)]
On May 4, 2010, at 11:07 AM, Devine, Karen D wrote:
Attached is a write-up of the "compromise" solution I promised after our discussion at bootcamp. I'm sorry it is late; I wrote it last week but forgot to mail it out.
Please read and consider it; then reply with your thoughts. Thanks!
Karen
<compromise.txt>
participants (2)
-
Devine, Karen D -
Mark Beall