TIP #78: TEA 2.0 Definitions


TIP:78
Title:TEA 2.0 Definitions
Version:$Revision: 1.4 $
Authors: Andreas Kupries <andreas_kupries at users dot sourceforge dot net>
Larry W. Virden <lvirden at yahoo dot com>
State:Draft
Type:Informative
Vote:Pending
Created:Saturday, 15 December 2001

Abstract

This document is an informational TIP providing definitions for commonly used terms (like package, extension, core, distribution, etc.) to make future communication among people in the community easier. It is recommended that future and past documents specifying details inside of the greater context of TEA refer to this document to ensure a consistent usage of terms.

Background

This document is an adjunct to the [TIP <<vision>>]. (DKF - Is this meant to be a reference to TIP #34? Edit to such if so...)

To facilitate the specification and adoption of clearly defined interfaces to various activities and technologies it specifies a number of terms used by the community at large to create a greater unity and coherence in the usage of these terms. In other words, by creating generally accepted definitions for important terms the risk of misunderstanding each other is reduced.

Specification of Technical Terms

This section specifies a number of important technical terms in alphabetical order. Terms used inside of a specification are highlighted.

Roles

The terms in the preceding section specified both passive data structures and actions upon them. This section specifies the possible actors, i.e. entities which perform one or more of these actions.

To make the specification easier, related actions are grouped into roles of behavior. The mapping from roles to actual actors, i.e. people and organizations is n:m. On other words, one actor may have several roles, either at once or changing over time and one role can be held by several distinct actors.

Examples are given at the end of this section.

  1. Catalog manager

    A catalog manager handles one or more catalogs. He is responsible for

  2. P/A Builder

    A package and/or application builder is a person and/or organization

  3. P/A Developer

    A developer is a P/A User whose tasks include the creation of new packages and/or applications. A workspace contains the raw sources of these new packages and applications. For posterity and version control it is kept synchronized with one or more source repositories.

    During development, at least one installation has to be accessible, containing the initial packages, the new packages and the applications built upon the packages.

  4. P/A User

    A person or organization which uses Tcl based tools but does not develop new code. Its workspace contains the files required for the tasks at hand.

    The border between the roles of P/A Developer and P/A User blurs if the tool being used allows one to customize/program/extend it in Tcl.

  5. Repository manager

    This role handles the management of all types of repositories. This role is not part of the development process per se and has no direct actions for with regards to distributions, packages, sources, etc.

    Repository managers are responsible for keeping the system up and running, doing adequate backups, supporting mirrors, providing browsing and download capabilities, providing confidence that updates to items in the repository are being done by the approved person or persons, etc.

    The role is related to System administrator, but not the same. It was split out of that role because a System-Administrator is usually internal to an organization whereas a repository and its management can be provided by an entity external to the organization.

  6. System administrator

    A system administrator manages

The three P/A roles are central to the development process and bound together in a tight loop of information flowing between them. The other three roles handle the support structure without which the other roles would be unable to communicate and collaborate.

Examples:

Visual Representation

The following drawings are a visual adjunct to the terms in the last sections to aid in the understanding of the terms and their relations.

Legend:

Roles, Data and Actions

Relationships Between Data Entities

Copyright

This document has been placed in the public domain.


Powered by Tcl[Index] [History] [Edit] [HTML Format] [Source Format] [LaTeX Format] [Text Format] [XML Format] [*roff Format (experimental)] [RTF Format (experimental)]

TIP AutoGenerator - written by Donal K. Fellows