Ken Irving - 2008-01-28

I have need for an object to know and use its name, something which it, strictly speaking, doesn't know.  The application is a web app, with several objects accessed via the Aggregate.do method.  The leaf objects need to put their name and a url in the output, but those things aren't necessarily available in the current setup.

I started in the typical fashion: straight on, head-first, creating some new options and dutiful populating them in the caller.  This of course works, but needs to be done explicitly for each use.

It finally dawned on me that I could use environment variables to serve this purpose, e.g., perhaps setting tob_object and tob_method as exported variables. Also, while I started thinking about the environment as a bash thing, that's far from the case, as it is a process feature provided by the kernel's fork and exec and the like functions.

In other words, environment variables could provide a useful means to achieve inter-process communication.  Actually, it would be a one-way communcation, so limited in scope, but still useful.

It probably makes sense to export a number of values in the original ``enabler'' call, though there's no need to go overboard with it.  I should heed the warning about over-worrying about new features, and just export what I need now.  For now I'm considering:

    tob_object_method
    tob_object
    tob_method
    tob_arguments

But not sure if it's worth doing the latter. Not now at least.

The others are simple enough, but already have some interesting characteristics.  The tob_object_method variable is stored early on, and is essentially as given by the caller.  The tob_object, on the other hand, while described in the thinob.sh as the ``nominal'' object, comes after resolving symlinks and colon-delimited contained objects, so may not be useful for the web page and links need I have for it.  The first form should be sufficient, however.