Locating Models

I got stuck figuring out how to reference models. The problem is that a reference to a Model by a Client needs to be one of three types:

1. Absolute. The reference to the model is the absolute path to the file containing the model.

2. Search-path-relative. The reference to the model is the path to the model relative to one or more directories in a search-path, called TIM_PATH. An icon or star library will typically be referenced this way.

3. Working-directory-relative. The reference to the model is relative to the directory that the client thinks is its "working directory." For example, an editor of a dataflow graph considers the directory in which the file describing that graph resides to be its working directory. This is typically used to reference related documents, such as nested dataflow graphs. The reason this is a problem is that models can be shared by many clients, but only one copy should exist in memory. Because of this, a naive implementation of the mechanism to search TIM_PATH for a given library (as I have now) has to re-search every time the model is accessed, because the working directory may be different from last time. I considered using a naming convention -- that is, anything starting with ./ is working-directory-relative -- but Christopher rightly pointed out that this is bogus.

   Here is what I came up with:

   
   

   
   The idea here is to effectively cache the path to a model's File (as in disk file, not the Tycho File class, which is actually a widget), and reference is by both the working directory and the relative path. Notes on the model:

   • ModelRegistry is a singleton class. (It's mis-named: it should be ModelLocator.) When a Client called its locate method with a given workdir and a relative path, one of two things happens:
     • The registry does not have a record of having located a model with that path and with that working directory specified. It searches the search path for that file. If the search path contains ".", workdir is used as the base for path.

       If ModelRegistry finds a matching file, it creates a ModelProxy object that knows where that file is. (In the implementation, the proxy is just some data in the ModelRegistry class -- the diagram is conceptual only.) A unique id is returned to the client.

     • The registry has previously located a model with that path and with that working directory. It returns its id.

     (A Client, by the way, could be another Model. I should perhaps have shown Model inheriting from Client to capture this role.)

   • The client must then link to the model by this id. If the Model is not already loaded into memory, the ModelProxy loads it, and returns a reference to it. Otherwise the reference to the Model is returned. A model will stay in memory for as long as any clients have a reference to it.

   • After the client no longer needs the model, it must call unlink on the model. It must provide the same key as it provided to link. If no clients are linked to the model, the model is deleted from memory.
   The key part of making this work is that a client is obliged to maintain its working directory. In the case of, say, a galaxy that contains a galaxy in a sub-directory, the paths of Models referenced by the sub-galaxy will be relative to its directory, not to that of its parent. As long as references are only down a tree (that is, a galaxy does not reference, say, ../icons/sources.tim), moving files and directories around should be fairly robust.

   
   JohnR, 14 Nov 97