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>