TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Re: Log on (in), sign on (in) -- technical distinction?
Subject:Re: Log on (in), sign on (in) -- technical distinction? From:Odile Sullivan-Tarazi <odile -at- mindspring -dot- com> To:Peter Neilson <neilson -at- windstream -dot- net> Date:Thu, 15 Oct 2009 11:05:06 -0700
Peter,
Thank you for helping me to make sense of the original distinction.
There was no supporting information in the MS style guide to explain
the basis of the decsion documented there.
So what you're saying is that now users *are* signing in through http
sites in what amounts to stateful connections -- but you still
wouldn't term it "logging in," because that state is achieved by
methods other than that (or those) used on an individual machine or
on a local network? Or are you saying that "log in" is okay for
those http connections which are stateful, while "sign in" ought to
still be employed for stateless connections?
If so, this is a distinction that is certainly more apparent to
developers! But I do love knowing where it all comes from.
Odile
At 11:24 AM -0400 10/15/09, Peter Neilson wrote:
>I can only give the techie distinction, which is stateful vs stateless.
>
>On a computer, or perhaps on a local network, logging in creates a
>state. A process for the user is established, and continues until
>the user logs out. Over the Internet, http connections are
>deliberately stateless, which is to say that your http request is
>treated as a single entity that is not intended to create a state
>(or a process) in the targetted host. It is a request, it gets a
>reply, and it is done.
>
>The burgeoning need for stateful connections over the http has
>resulted in various methods for signing in, where the host system
>establishes a cookie within the user's browser, or does some other
>action to identify and remember a particular user. It's not a
>trivial problem, because a server that's taking care of sequentially
>related transactions for thousands of users must recognize each and
>distinguish among them, even in the face of some of them trying to
>steal the identities of others.
>
>Those who are in charge of systems where users log in and log out,
>such as the Linux system I'm using right now, do not like to see the
>term "log in" used for stateless Internet connections. Hence "sign
>in." The rest of the world apparently see the terms as
>indistinguishable.
>
>Historically, the terms LOG ON versus LOG IN (and the commands LOGON
>versus LOGIN) tended to be IBM versus most everyone else. But that's
>outside the current discussion. Gee, I'm doing a lot of that,
>recently.
Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices. http://www.doctohelp.com/SuperPages/Webcasts/
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-