Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!pds From: pds@quintus.UUCP (Peter Schachte) Newsgroups: comp.sys.amiga Subject: Re: Ban the Cloud! (plus sugg. for Workbench) Message-ID: <853@goedel.quintus.UUCP> Date: 5 Apr 88 20:35:14 GMT References: <318@jc3b21.UUCP> <357@jc3b21.UUCP> Organization: Quintus Computer Systems, Mountain View, CA Lines: 119 Keywords: Workbench In article <357@jc3b21.UUCP>, fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > what do you do if the system crashes before the file is > deleted? If the file is confined to RAM: we wouldn't have a problem. > Another option which might be simpler would be to simply write the data to a > buffer in memory. This seems reasonable. Actually, what I had in mind was to create the file in ram:, but when that starts to fill up, to move it over T:. As you pointed out, many people have much more free memory capacity than free disk space. That's a good point, I've been assuming that before TOO long, most Amigas would have hard disks. This doesn't seem to be coming to pass (I don't have one yet), as the prices haven't fallen the way I'd expected them to. Anyway, I was mostly trying to describe the way the system would feel to the user, rather than how it could be implemented. How about this: the file would be written to MAGICSTORE:, which you could assign as you pleased. Not as efficient as your idea of allocating memory for the bytes, but easier to implement and customize. > Nothing is left around unless the user asked that it be kept. (...if the system crashes.) Good point. But there are advantages to having it remain around in MAGICSTORE:. Suppose when MAGIC: is mounted, it does a directory of MAGICSTORE:, and automagically opens a magic window viewing it. That way your intermediate data wouldn't necessarily be lost on a system crash. > > ... Ideally, there would be a > > way to specify what arguments the program takes, and the super-WB would > > use this to prompt users for this info in some simple, consistent, and > > non-troublesome way. > > I'm not sure that's the ideal. I think the programmer and > the user have to know about the arguments the program takes. The programmer > who writes for naive users needs to find some more friendly mechanism than > command line options. That defeats (part of) the purpose for the whole thing. My goal is that users be able to use more complex tools that are too intimidating now, not because of the tool, but because of its line-oriented interface. Therefore, there should be a language for programmers to specify the arguments their program expects, and their types, and supply help information for it, and the super-WB would have a part that could put up a panel to prompt you for this information, and give you help with it. If this were well-designed, it shouldn't be any slower to use than a command-line interface, and would save you from having to remember all those cryptic switches. > But how do you redirect input? How do you tell the super-WB the file > handle should point to a disk file instead of an input window? Selecting > the files and dropping them on the program's icon (or using the present WB > system for selecting the files and double-clicking on the program's icon > should pass the names of the files as command line parameters. You still > need something equivalent to "<" on your workbench screen. I think you're saying that we need a way to distinguish between passing a file on the command line (which you say is the equivalent of shift-double-click) and passing them as standard input. I was thinking of shift-double-click as specifying stdin, and not command args. I think the reason I didn't draw the distinction is that many (most?) unix tools will take either standard input or (a) file name(s) on the command line, and supplying file names is equivalent to piping them to stdin. For tools like this, the interface description (seems like a good name for the language that specifies the arguments and switches a command expects) would specify this fact, and then shift-double-clicked files would be piped to stdin. For programs that take several files as input, the interface description would specify which are specified by shift-double-clicking. For example, you might want diff to allow you to shift-click two files and then double click the diff icon in order to diff those two files. And lpr (let's call it print) would specify that it wants an arbitrary number of files, but doesn't want them piped to stdin (so that it can put the file name at the top of each page). I'm appealing to the interface description, which isn't even designed yet, to handle this problem. But I'm hopeful. > > > The program shouldn't know or > > > care whether it was started from a CLI or from Workbench. > > > > Agreed, almost. I think the tool types of the WB are a very useful > > facility (which should be extended). I wouldn't want them to go away. > > I'm not sure the tool types are that important. More important is > knowing the default tool.... > Tell me more about how you think the tool types should be used. Ok. This is an excerpt of a posting I made a while ago in this discussion. o Make COPY look inside an .icon file for a specific copy program to run in order to copy that icon. Not finding one, copy as usual. Similarly for delete, rename, etc. This would make WB more object-oriented, and would allow icons to represent more than a single file, for example. o To get REALLY fancy with this idea, allow a file (or it's .icon) to specify methods for opening, writing a buffer to, reading a buffer from, seeking in, etc., that file. This would allow some really WONDERFUL things, e.g., files to be stored in compressed form, but still be read and written by ordinary programs oblivious to the storage technique. Or source code files could be stored in pre-parsed format, and be greped, printed, etc., as usual, but editors and compilers could have special knowledge about reading them in as pre-parsed files. The possibilities are endless. I know it sounds pretty radical, but I have some ideas on how to implement it. I think it could make the Amiga about the best-integrated microcomputer environment going. I didn't make it clear, I realize now on rereading, but I was talking about tool types. It would be really great if a tool type specified a METHOD, in the object-oriented sense, for doing something to that file. This would make each file, in some sense, like its own device. This could be VERY powerful. I'd like the super-WB to do this, but I'm afraid it would need the cooperation of the exec. Anyway, this is how I'd like to see tool types used. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds