Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!umd5!feldman From: feldman@umd5.umd.edu (Mark Feldman) Newsgroups: comp.sys.next Subject: -host option (was Re: NeXT alternatives) Message-ID: <4683@umd5.umd.edu> Date: 10 Apr 89 14:54:42 GMT References: <12192@reed.UUCP> <245300010@uxe.cso.uiuc.edu> <688@garcon.cso.uiuc.edu> <41358@tut.cis.ohio-state.edu> <8277@polya.Stanford.EDU> Reply-To: feldman@umd5.umd.edu (Mark Feldman) Distribution: usa Organization: University of Maryland, College Park Lines: 32 In article <8277@polya.Stanford.EDU> aozer@NeXT.com writes: ... > >You can run an application on one NextStep machine and have the windows >appear on another simply by specifying the destination host with "-host". > >Ali Ozer Under 0.8, the -host option is not well documented. I scanned through the tech refs and didn't see it. If it is documented, it certainly doesn't stand out. The problems with the -host option that appear immediately are: While the visual part of the interface appears on the target machine, sounds are produced on the source machine (I assume that all DSP-related action run on the source machine). Using the -host option, anyone can put windows on YOUR NeXT. There doesn't appear to be an equivalent to the X xhost command. There is no way to determine at a glance on what machine an application is running. Having Workspaces, Edits, and whatnot on your NeXT from other NeXTs can be quite confusing. Perhaps 0.9 will fix some of these failings. On the other hand, the -host is very useful (Now I can Edit remotely -- emacs is nice, but when your vt100 isn't really...), and any application written using the application kit can be -hosted. Mark