On Wed, Sep 07, 2005 at 07:36:23AM -0400, Timothy Miller wrote:
> On 9/7/05, Jack Carroll <[EMAIL PROTECTED]> wrote:
>
> > We're getting close to actually assigning some numbers to parts and
> > doucments.
> > Where are we going to keep the number logs? Conventional
> > single-site drafting departments almost always keep number logs on paper
> > with pencils, so that computer accidents (or the obsolescence of entire
> > generations of computer technology) don't result in irrecoverable chaos.
> > Does Traversal have an office yet? Or is the team permanently dispersed?
> > If the latter, maybe the best possibility is to keep the live number logs
> > on-line as wikis, and establish a procedure to back them up on floppies at
> > several locations at set times. Good floppies last at least 25 years, and
> > plain text on IBM-formatted media is not going to go obsolete in the
> > foreseeable future. Hard copy is more permanent, but floppies can be
> > uploaded for restoration or hardware replacement.
>
> We're dispersed for now, possibly permanently. A wiki would be good,
> but do we need to be bothering the world with our internal part
> numbers?
No. We only need a way for those participating in Traversal design
work, and OGP document creation, to take new root numbers from the log
without risk of conflicting with somebody else's assignment of a root
number.
I know how to do that in a conventional single-site engineering
department, where the hardcopy number log sits on the Drafting clerk's desk.
You walk over to the log, write the next unused number on the next empty
line, fill in the description field, and add your name and the date.
I've never dealt with managing number logs in a multi-site
organization where every designer doesn't have physical access to a single
paper log. So I'm brainstorming the problem.
For discussion, I'll call everyone who initiates creation of a
document, or addition of a part to inventory, a "designer".
REQUIREMENTS
1. Every designer must be able to see what numbers have previously been
assigned in the root number log, right up to the minute. The efficient way
to do this is to read the whole log in raw form, not peek through the
keyhole of a search engine.
2. At all times, every designer must be able to assign an available number
to a description, and immediately make that assignment visible to any
designer who looks at the log. Waiting until the start of the next work
shift for a central clerk to respond is inefficient, therefore not
acceptable. Since the numbering system standard permits any unassigned
number to be taken, not just the next number in sequence, a designer must be
able to assign any number that is not already assigned.
3. A designer must be able to view the log or assign a new number remotely
over the Internet.
4. Assignment of a number is generally irrevocable, and a vital operational
record for the organization. Any loss of previous log entries (or any other
engineering documents) can have extremely serious consequences, such as
multiple parts or drawings with the same number, or lost designs. Backup
and data integrity procedures must be designed to preserve the log content
forever against all hazards.
POSSIBLE APPROACHES
1. Requirement 3 means that the number log has to be on-line, and editable
over the Net.
2. Plain text files can be edited by the widest variety of tools on the
widest variety of client platforms. Wiki on the server side allows text
files to be edited remotely. So Wiki is a possible server-side tool for
number logs. A major reason to consider Wiki is that it can be set up with
minimal effort for immediate use in the early days of the company, when
little manpower is available to work on infrastructure.
3. A single log file is easy to download and preserve on floppies or CDs.
Whoever assumes the role of Drafting clerk (and somebody will have to) could
establish a regular schedule for downloading the log and archiving it
off-line, probably as diffs.
4. The weak point of a Wiki is that it allows people to edit other people's
log entries. This could result in accidents, which would require the clerk
to upload an older snapshot and merge it with the newest entries.
For that reason, we might want to move later to a more rugged log
system. That would require thought and planning. For instance, the log
might be turned into a directory tree, with each entry becoming a separate
text file. That would allow individual entries to have file owners, so that
only the author and the clerk would have write access. A cron job could
shut off write permissions for each entry after a certain amount of time,
maybe 2 days, so that special action would be needed to alter it after that.
But new entries could still be added freely.
If we were to turn the log into a directory tree, requirement 3
demands that the action of adding an entry should trigger the immediate
update of the text file that shows the whole log.
5. Reliable 24/7 write access to the log requires at least 2 log file
servers in different locations. Coherence, and prevention of duplicate
entries, is a primary requirement. A possible solution is to assign rank to
the servers, with clients writing only to the master server, the master
writing its newly accepted entries to the first slave, and so on down the
ranking order. If a server goes off line, it goes to the lowest rank when
it comes back up, and every server below it moves up one rank. Maybe
somebody with DBMS experience has a better idea.
6. The logs must outlive the computers and operating systems they run on,
by many generations. This suggests that any applications and scripts used
to manage them should use the simplest, most generic facilities possible, so
that they can be carried forward intact if possible, and ported if not.
All modern operating systems implement the simplest and oldest Unix
utilities and scripting languages, so we would probably be safe implementing
log servers and maintenance scripts using those facilities.
One advantage to building the permanent number log system in a
Unix-oid environment (Linux, BSD, Mac-OS X, or whatever) is that it gives us
user accounts, file permissions, and all the security features they bring
along. We could require people to join the project and get a user account
on the server, to be considered "designers" and gain write access to the
number log. These basic Unix features are likely to be preserved in future
operating systems for many decades to come.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
