Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!hellgate.utah.edu!cc.utah.edu!inel.gov!tws1!dob Newsgroups: comp.windows.x Subject: Re: Spy X Window Message-ID: <1990Jul26.193900.26903@inel.gov> From: dob@tws1.Berkeley.EDU (David L. Brooks) Date: Thu, 26 Jul 90 19:39:00 GMT Sender: news@inel.gov References: <1990Jul17.140940.10553@inel.gov> <212@trwacs.UUCP> Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho Lines: 67 In article <212@trwacs.UUCP>, epstein@trwacs.UUCP (Jeremy Epstein) writes: |>In article <1990Jul17.140940.10553@inel.gov>, dob@tws1.Berkeley.EDU (David L. Brooks) writes: |>[much stuff deleted] |>> |> |>Way back in the dark ages (late 70s-early 80s) was an operating |>system named TOPS-20 (aka TWENEX) which ran on the DECsystem-20. |>One of the more useful features was an "advise" command which |>allowed you to see what someone else was doing and help them out. |>To get advice, you would say something like "advise fred" and fred |>would get a message saying "sally wants to advise you, is that OK?". |>If you answered no, the system would not permit the advise. |> |>As an aside, there was also some sort of a "spy" command which could |>be used (I think) only by appropriately privileged users. |> |>I assume other people have implemented similar things for other operating |>systems, as well as for various windowing systems. These are very useful, |>and provided that they are implemented properly do not provide for |>snooping/eavesdropping/spying. |> |>The rub: the X architecture doesn't lend itself extremely well to |>asking the user of an X server whether it's OK for another user to |>connect...other than using the authentication mechanisms, which |>isn't as useful as an interactive approver. Of course, you could |>implement various clients which would play go-between. |> |>If anyone out there has something similar to "advise", I would be |>most interested in getting a copy. |>-- |>Jeremy Epstein TRW Systems Division |>UUCP: uunet!trwacs!epstein Internet: epstein@trwacs.fp.trw.com |>+1 703/876-8776 Mr. Epstein has a good example with "advise". X provides mechanism, not policy. I think an "xadvise" (that's not a commitment on my part!) would have to implement the desired policy. In the example given above, perhaps "sally" would have a program listening on some public port for requests from "fred" and his cronies. when "fred" asked for help, "sally" would respond, and "fred" would get the opportunity to accept or refuse the offer (this would be handy if there were more than one offer of help). "fred" could then mark off some region of his screen, which periodically "sally" would then see. advise could go on in some set of text dialog windows... ------------------------------------------------------------------------------ David L. Brooks Idaho National Engineering Lab. INTERNET: dob@INEL.GOV POB 1625 M.S. 1206 Phone: (208) 526-0826 Idaho Falls, Id. 83415 FAX: (208) 526-1419 ------------------------------------------------------------------------------ Neither the United States Government nor the Idaho National Engineering Laboratory nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the Idaho National Engineering Laboratory. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the Idaho National Engineering Laboratory, and shall not be used for advertising or product endorsement purposes.