feldman@umd5.umd.edu (Mark Feldman) (04/10/89)
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
wsd@cs.brown.edu (Wm. Scott `Spot' Draves) (04/11/89)
In article <4683@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes: 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. Not only is the use of this option undocumented, but how to write a program that does this yourself is also undocumented. Any clue how to do this? Scott - - - - - - - - - - Scott Draves | Space... The Final Frontier wsd@cs.brown.edu | uunet!brunix!wsd wsd@browncs.bitnet Box 2555 Brown U Prov RI 02912
bob@tinman.cis.ohio-state.edu (Bob Sutterfield) (04/11/89)
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". Does this use Berkeley sockets or Mach ports? In article <4683@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes: While the visual part of the interface appears on the target machine, sounds are produced on the source machine Oops! :-) Fixed in 0.9? ...any application written using the application kit can be -hosted. If one had sources, one could write using the application kit on any arbitrary machine, anywhere on the internet, just like with X or NeWS. The crunching would happen on yon Cray, and the user interface (hopefully including the sound) would happen on the user's desk. Is this beginning to sound like a broken record?
avie@wb1.cs.cmu.edu (Avadis Tevanian) (04/11/89)
In article <4683@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes: >In article <8277@polya.Stanford.EDU> aozer@NeXT.com writes: > 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). In 0.9, this problem is avoided in two ways. First, we have added a Postscript operator to play a sound, so if your application does something simple like a system beep, it comes out in the right place. If you are making more intense use of sound, then by default, the sound does come out on the machine you run an app. However, the sound library allows you to set which host you wish to have sound come out on. Of course, if you are playing back 44Khz, stereo sound, you best bet is to play it on your local machine and get the data from your local disk, the network just won't cut it. > Using the -host option, anyone can put windows on YOUR NeXT. There > doesn't appear to be an equivalent to the X xhost command. In 0.9 we have added some very nice security features using the fact that Mach provides kernel protected capabilities (ports). In the Preferences application (which will be shipped in 0.9), you can select whether or not your Window Server (Display Postscript) is public or not. If your Window Server is private, then only children of loginwindow may put windows on your screen. This means that you are even prevented from having someone rlogin into your machine, su to you (if they can), and start putting up windows. If you live in a friendly environment, you can make your Window Server public, and anyone can connect. To make a Window Server semi-public, you can write a short program that you would run after logging in, and it would hand out the Window Server port to whomever it decided it wanted to. And of course, since ports are network transparent, they can be handed out to any machine on your network. I'm not sure if we'll be shipping such a program in 0.9, but it will be interesting to see if anyone comes up with interesting ways to do this (like, ask for a password, for example). > Mark -- Avadis Tevanian, Jr. (Avie) Chief Operating System Scientist NeXT, Inc. avie@cs.cmu.edu or avie@NeXT.com --
ali@polya.Stanford.EDU (Ali T. Ozer) (04/11/89)
In article <4683@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes: > >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). > 0.9 addresses this problem somewhat by providing the server with means to generate sounds (PostScript operator to generate sounds, anyone?). This operator is really meant for beeps, sounds tied to buttons, and other short sound segments... Under 0.9 you do not get the nice features of the soundkit when you generate sounds through the window server. > Using the -host option, anyone can put windows on YOUR NeXT. There > doesn't appear to be an equivalent to the X xhost command. > In 0.9 a user can prevent other machines from putting windows on his/her machine. This is done by specifying whether you want your window server to be "public" or not. Ali
jdn@mas.UUCP (Jeff Nisewanger) (04/13/89)
In article <4683@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes: >In article <8277@polya.Stanford.EDU> aozer@NeXT.com writes: > 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). In 0.8 sound is done through /dev/sound0. I thought I heard that in 0.9 (?) sound could be done through a Mach port instead of a /dev entry. I was figuring one of the reasons for this was so sound could be done across the network using the Mach port just like the Mach port being used for the NeXT window system. Is this something that just isn't ready yet or is there a reason why this wouldn't work? Jeff Nisewanger Measurex Automation Systems ....apple!mas1!jdn
wsd@cs.brown.edu (Wm. Scott `Spot' Draves) (04/17/89)
In article <WSD.89Apr10141142@gano.cs.brown.edu> wsd@cs.brown.edu (Wm. Scott `Spot' Draves) writes: In article <4683@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes: 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". Not only is the use of this option undocumented, but how to write a program that does this yourself is also undocumented. Any clue how to do this? It seems that any program written with the Application Kit will support -host (thanks to those who mailed me; I'd credit you but I deleted the mail. sorry). That is nice, but what if I want my program to throw windows up on four different machines and interact with those users simultaneously. NextStep needs more network support than "run me on another machine". Much more. Scott - - - - - - - - - - Scott Draves | Space... The Final Frontier wsd@cs.brown.edu | uunet!brunix!wsd wsd@browncs.bitnet Box 2555 Brown U Prov RI 02912