Received: by nummer-3.proteosys id <01C19443.4E18A4EC@nummer-3.proteosys>; Thu, 3 Jan 2002 11:42:13 +0100 In-Reply-To: Your message of Mon, 11 Nov 91 14:05:18 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.4E18A4EC" Return-Path: <@vm.gmd.de:LATEX-L@DHDURZ1.BITNET> X-MimeOLE: Produced By Microsoft Exchange V6.5 x-vm-v5-data: ([nil nil nil nil nil nil nil nil nil][nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]) x-to: LaTeX-L Mailing list Content-class: urn:content-classes:message Subject: Re: automatic update Date: Tue, 12 Nov 1991 00:47:15 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Nelson H. F. Beebe" Sender: "LaTeX-L Mailing list" To: "Rainer M. Schoepf" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 456 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.4E18A4EC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Leslie Lamport writes: >> ... >> I am thinking about the possibility of a system for using e-mail to >> implement distributed applications. A "demon" would remove the >> appropriate messages from the user's inbox and interpret them. (For >> operating systems that couldn't accomodate this, the user would have >> to do something manually to get the message processed.) >> ... My remarks here are absolutely not intended to denigrate Leslie Lamport's proposal, but only to expose some of the difficulties such a project faces. I, and many other archive maintainers, would dearly love to have a workable system. In the absence of a global file system (global meaning encompassing Planet Earth), an e-mail distribution system might be the next best thing. While e-mail updating would handy (and tex-archive@math.utah.edu would reach 55+ sites for updating TeX distributions), there are at present some difficult problems that have to be solved to make an automatic update possible. In many cases, the problems are not controllable, or soluble, by a single person or even organization. First, e-mail is often unreliable for several reasons: (a) truncation of messages beyond a certain byte limit; (b) truncation of long lines; (c) transliteration of characters, particularly passing through Bitnet or other non-ASCII gateway machines, or from 8-bit to 7-bit = environments; (d) non-arrival of messages (a gateway along the mail path silently loses them); (e) non-delivery of messages (host was temporarily down, or address is no longer valid; every human mailing list maintainer battles this problem with every mailing); (f) e-mail is not yet as universally available as the telephone system, but within a decade or two, will be. Encoding schemes like vvencode will address (a)-(c), if the developers in the UK ever turn it loose. Internet mail software people are also working on these issues. Second, file updates often depend on previous ones; automatic deposit of new versions, or application of file differences like the UNIX patch utility does, can corrupt or otherwise invalidate an existing system. For example, when TeX 3.0 came out, several macro files were updated to require 3.0. These cannot be installed on a pre TeX-3.0 system. There is absolutely no way to keep all sites at the same software level. Indeed, I do not expect this to ever be possible. The reasons are many, all due to lack of x, where x is resources, money, licensing, trust, ... In the case of TeX, both public and commercial implementations are in use; most commercial one lag far behind the public ones because of their slower distribution channels, and the effort needed to prepare a commercial-quality software distribution to licensed customers. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C19443.4E18A4EC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: automatic update

Leslie Lamport writes:
>> ...
>> I am thinking about the possibility of a = system for using e-mail to
>> implement distributed applications.  A = "demon" would remove the
>> appropriate messages from the user's inbox = and interpret them.  (For
>> operating systems that couldn't accomodate = this, the user would have
>> to do something manually to get the message = processed.)
>> ...

My remarks here are absolutely not intended to = denigrate Leslie
Lamport's proposal, but only to expose some of the = difficulties such a
project faces.  I, and many other archive = maintainers, would dearly
love to have a workable system.  In the absence = of a global file
system (global meaning encompassing Planet Earth), an = e-mail
distribution system might be the next best = thing.

While e-mail updating would handy (and = tex-archive@math.utah.edu would
reach 55+ sites for updating TeX distributions), = there are at present
some difficult problems that have to be solved to = make an automatic
update possible.  In many cases, the problems = are not controllable, or
soluble, by a single person or even = organization.

First, e-mail is often unreliable for several = reasons:

(a) truncation of messages beyond a certain byte = limit;
(b) truncation of long lines;
(c) transliteration of characters, particularly = passing through Bitnet
or other non-ASCII gateway machines, or from 8-bit to = 7-bit environments;
(d) non-arrival of messages (a gateway along the mail = path silently
loses them);
(e) non-delivery of messages (host was temporarily = down, or address is
no longer valid; every human mailing list maintainer = battles this
problem with every mailing);
(f) e-mail is not yet as universally available as the = telephone
system, but within a decade or two, will be.

Encoding schemes like vvencode will address (a)-(c), = if the developers
in the UK ever turn it loose.  Internet mail = software people are also
working on these issues.

Second, file updates often depend on previous ones; = automatic deposit
of new versions, or application of file differences = like the UNIX
patch utility does, can corrupt or otherwise = invalidate an existing
system.  For example, when TeX 3.0 came out, = several macro files were
updated to require 3.0.  These cannot be = installed on a pre TeX-3.0
system.

There is absolutely no way to keep all sites at the = same software
level.  Indeed, I do not expect this to ever be = possible.  The reasons
are many, all due to lack of x, where x is resources, = money,
licensing, trust, ...  In the case of TeX, both = public and commercial
implementations are in use; most commercial one lag = far behind the
public ones because of their slower distribution = channels, and the
effort needed to prepare a commercial-quality = software distribution to
licensed customers.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Nelson H.F. Beebe
Center for Scientific Computing
Department of Mathematics
220 South Physics Building
University of Utah
Salt Lake City, UT 84112
USA
 Tel: (801) 581-5254
 FAX: (801) 581-4148
 Internet: beebe@math.utah.edu
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

------_=_NextPart_001_01C19443.4E18A4EC--