twakeman@hpcea.CE.HP.COM (Teriann Wakeman) (12/22/88)
>What I would like to see is the desktop metaphor extended into 3D, say >for example, an office. You would have a desktop, a trashcan, a phone, >an inbasket/outbasket, a filesystem, etc. Each of the services that are >offered by the system are represented as an object in the office. This part has been done before. Around '85 there was a comercial finder replacement out that had a 3-d office. You clicked on objects to use them. It came with several utilities to extend the desk top metafor, such as a rolodex on the desk that pulled up a rolodex program, phone for telecomm program & so on. The product was a flop. Considering the advertizing done, I suspect this was a real money losser. I might support the idea of multiple desk tops each customizable to different tasks. Key would be the ability to have an Icon reside on multiple desk tops all pointing to a single application. I simulate multiple desktops with hard disc partitions. Each partition is set up for a different primary use. The real problem is if I want to be able to use an application from multiple partitions, I need multiple copies of the application taking up precious disk space. Also, I have not yet found a HP partition application I am completely happy with yet. TeriAnn
barmar@think.COM (Barry Margolin) (12/23/88)
In article <8939@ut-emx.UUCP> osmigo@emx.UUCP (Ron Morgan) writes: >I don't know why a wireless keyboard would be far-fetched. Hardly far-fetched, since it was done in a commercial computer several years ago. The original IBM PC Jr had a wireless keyboard that used infrared signals. They eventually punted it because it didn't work too well. Input would be missed because someone would walk between the keyboard and the PC, and it could get confusing with multiple machines in the same room. Wireless communication is pretty noisy and error prone. It is well suited to low-bandwidth applications such as telegraphy, or less error-sensitive applications such as voice. For applications such as terminal I/O integrity is important, so you would need an error-detecting protocol between the PC and the device. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
landman%hanami@Sun.COM (Howard A. Landman) (12/28/88)
>In article <8939@ut-emx.UUCP> osmigo@emx.UUCP (Ron Morgan) writes: >>I don't know why a wireless keyboard would be far-fetched. In article <34173@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: >Hardly far-fetched, since it was done in a commercial computer several >years ago. The original IBM PC Jr had a wireless keyboard that used >infrared signals. They eventually punted it because it didn't work >too well. Input would be missed because someone would walk between >the keyboard and the PC, and it could get confusing with multiple >machines in the same room. >Wireless communication is pretty noisy and error prone. It is well >suited to low-bandwidth applications such as telegraphy, or less >error-sensitive applications such as voice. For applications such as >terminal I/O integrity is important, so you would need an >error-detecting protocol between the PC and the device. Just because IBM's implementation failed to address the important issues and was unreliable, is no reason to punt on the concept. We already know of systems that face the same kinds of difficulties and work fine. Ethernet is one example, and even the old ALOHA packet-radio network worked well enough. Implementing this at keyboard bandwidths should be childsplay. If someone walking between keyboard and computer interrupts communication, the keyboard should retry until the data is received. Of course, to do that it has to *know* whether the data was received or not! Howard A. Landman landman@hanami.sun.com
barmar@think.COM (Barry Margolin) (12/28/88)
In article <83075@sun.uucp> landman@sun.UUCP (Howard A. Landman) writes: >In article <34173@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: >>Wireless communication is pretty noisy and error prone. It is well >>suited to low-bandwidth applications such as telegraphy, or less >>error-sensitive applications such as voice. For applications such as >>terminal I/O integrity is important, so you would need an >>error-detecting protocol between the PC and the device. >Just because IBM's implementation failed to address the important issues >and was unreliable, is no reason to punt on the concept. I never said the concept was worthless, it just has some problems, and the one large-scale implementation of it didn't work too well. > We already know >of systems that face the same kinds of difficulties and work fine. >Ethernet is one example, and even the old ALOHA packet-radio network >worked well enough. Implementing this at keyboard bandwidths should be >childsplay. A big difference between wireless networks and a wireless keyboard is power levels. Packet radio and microwave ethernets can use higher power, so small disturbances aren't as likely to disrupt communications. >If someone walking between keyboard and computer interrupts communication, >the keyboard should retry until the data is received. Of course, to do that >it has to *know* whether the data was received or not! That's what I meant when I said that an error-detecting protocol is needed. The protocol would also need to be able to recognize and discard duplicates, or else you'll get duplicate keystrokes when the acknowledgement is lost. To do this generally requires a processor and memory, which would make the keyboard noticeably more expensive. I'm currently skeptical that the benefits of a wireless keyboard (I can't think of any myself -- why does the keyboard ever need to be more than a foot or two from the monitor?) are worth the cost of materials and development (not large, but not trivial, either). By the way, the original article I was responding to also suggested a wireless display (this would answer my question about why the keyboard should be far from the monitor -- the keyboard/monitor combination might want to be far from the CPU). In this case, the bandwidth requirements are much higher. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar