The acronym ETEN (Exhaustive Tcl Extension Network) was coined by Charles L. Brooks [L1 ], Murray S. Mazer [L2 ] and Frederick J. Hirsch [L3 ] in their paper [L4 ] for the Tcl'98 conference. Many thanks to them for this.
ETEN is the archive part of the overall infrastructure. It manages all packages created by the various users, the dependencies between, documentation, etc. Another important exported functionality is the ability to search for and retrieve managed packages.
It has been suggested that a more catchy name may be helpful.
Related page: Cantcl
I recommend you modifie the acronym to TEEN Tcl Exhaustive Extension Network
Let's start with the overall architecture of this thing.
It is currently composed of 3 interacting layers:
Here is a picture.
It expresses some more ideas, which are not necessarily obvious:
The architecture described above seems to be very flexible, but its implementation will be much more complex than for simpler ones. Is that worth the effort ?
I believe it is, and will try to explain that in coming paragraphs.
Let us start with a one-layer architecture.
There is essentially one application performing all tasks, from the management of the physical storage, the indices and up to the user interface. This architecture looks conceptually simple, but that is about its only advantage. Among the disadvantages are:
The next step is a two-layer architecture, it differentiates between archive and user interface. That already solves the issues above, but introduces a new one, stemming from the fact that technical systems like this do not float in the air by themselves, but are embedded in society.
The problem is this: To solve the second point in the last list we have to create more than one archive server. This introduces the necessity for synchronization, but this is only a technical problem. Well, partly, cause the data transfer required for syncing the archives may cross borders between countries and therefore systems of law. And these laws may forbid the transfer at all. The easiest example for this are cryptographic packages (like Trfcrypt [L5 ]) which can be imported into the United states without a hitch, but exported only under very restricted circumstances.
So, to avoid violation of law we have to base the synchronization facility on a framework which is able to permit or forbid a transfer based on information about the involved archives and information in the package description of the package to copy around.
The solution in the last paragraph stays in the boundaries of the two-layer architecture, but does not address all of the arising problems. Which/what was forgotten ?
The user. In the two-layer architecture indexing and physical storage are coupled together. Disallowing a transfer between archives causes a fragmentation of the index information as well, and the user has to know in which archive/index to search for a specific functionality !
There are 2 solutions to this:
Some more remarks: