dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/13/86)
>>My original messages (Matthew Dillon) >Michael Wagner (wagner@utcs or ...utzoo!utcs!wagner) replies My reply >>Solution: >> In this case, it is obvious that the WorkBench ICON structure should >> be modified. Specifically, it is obvious that the ICON's should all > >Can not agree. It is not obvious (for reasons to be presented furthur on). >Incidentally, I think you are guilty of having (in logic terms) used a >conclusion as an assumption. I didn't say that we *shouldn't* modify DOS.. if you've been reading, you'll note that I've posted quite a bit of information regarding improvments to DOS. What I infer here is that the WorkBench will work better using this new method rather than the old no matter what we do to DOS. >> be stored in a single file for each folder because this is what >> DOS is best at... finding a known file and reading its contents. > >Careful! We know something has to change. Your point here is that this >version of DOS is good at finding files (and poor at doing wildcards, >although you forgot to say that). Therefore, few changes would have to >be made to the DOS in your scheme. Now, look at the other side. All >sorts of things would have to change in the icon world. The current >icon code is clearly poor at doing those new things (in fact, it can't >at all, currently). The logic here, is, basically, lets compromise and >do it the way I'm already doing it. "The way I'm doing it now" is at best >an implementation detail. What happened to all the idealism about the >'right' way to do things that pervaded your original posting? Careful yourself. Don't attach improper meanings to my words. I'm well aware that any directory traversal is slow, but that's NOT what I was talking about here. From: wagner@utcs.uucp (Michael Wagner) >> The results: >> >> (A) No directory searches need be done >You should add "...to open windows". Directory searches are still >done a lot in amigaDOS (and applications). In fact, this lack is >one of the ones striking enough to merit your cries of 'the software >should be fixed pronto'. Wildcards are hopelessly slow in amigaDOS. >In fact, producing a list of all files in a directory (without wildcards) >is ridiculously slow. I commented on this over half a year ago. >(tongue in cheek) It is clear that the directory structure must be >changed (!). (tongue back out of cheek) See my notes about this on >the net at the time. The major problem is that file names are not >stored together in one place (much easier to arrange than icons all >in one place, let me tell you). As an (overly expensive) hack to >avoid the need for immediate change, I pointed out that a disk >sector cache would ease the pain, at cost of memory. Again, your attach improper meanings to my words. Don't you think I know all about that? Jeeze, I've written many programs that do directory traversals (for instance, my shell's filename expansion routines). >Most existing end-user applications that I've seen interface to the >file store by opening a requestor window, and giving you a list of >files in your current directory. This takes too long. The paying >end-users are going to get impatient. Fixing this problem will also >fix the icon problem, and will make the machine much faster at the >interface where it's going to make money (applications). Taking a CLI approach, this is what you get. Taking a workbench approach (in the formal sense), and using the new workbench scheme (everything in a single file), any file that the application would require would have an ICON for it, and thus no directory seaches would need to be done. DON'T ATTACH AN IMPROPER MEANING TO WHAT I JUST SAID! I'm am talking specifically about a workbench approach to the problem. >> (C) The directory/folder structure is retained > I'm not sure its fair to say the structure is retained if you're > going to change what goes into the folders dramatically. The structure is retained: Folders will still be directories, and their icons will be in a single file IN that directory. I didn't I wanted workbench to be unified over everything, just on a per-folder (directory) basis. >> (D) The fix can be propogated without invalidating any software >> to date by the simple distribution of a new workbench and a >> utility to convert from the old (multiple files) to the new. > I'm not sure this is true (although it may just be my own ignorance). > I expect there exist applications which have knowledge of .info files. > Besides, it misses a major point. Icons as files had a very important > property...they were just files. Everything I know how to do with a > file I know how to do with an icon. I can copy it, rename it, move > it...all knowledge I already possess (if I know how to use amigaDOS). > (we will leave aside the fact that, on the WB interface, the icon is > inseperable from the object it represents). If you remove the property > of icon==file, you now have to supply me with commands to copy, rename, > erase and otherwise manipulate the icons. Too bad, that. You're > basically advocating building your own (sub)filing system inside the > amigaDOS filing system because you've given up on theirs. That means > you have to re-do the whole show. Although I can't give specifics, > because I haven't thought about it enough, I can't believe it's going > to be easy. The hardest part is that it's a user-visible change > (well, amigaDOS-user visible, anyways). I don't suppose you ever looked at the ICON library? In Any case, in answer to your question, the WORKBENCH ITSELF has routines to do almost everything, and if this fix were made to the workbench, a couple of new menu options would be added to do everything else. YES it means that you can no longer move things around with amigados COPY, DELETE, and RENAME commands. Thus I'm only advocating that people begin using what's already there... the workbench. There is no reason, however, that a new CLI command couldn't be written to handle such options (for people who never use the workbench like me). Its a developer/programmer/hacker visable change, but your everyday user who doesn't understand what a CLI is will only see the performance increase. >> (B) Applications now have a new way of finding specific information >> (like DPAINT files) by having that information be represented >> by N ICONS (all of which can be accessed almost instantaniously). > It's huh time again. Matt, I'm not even sure what this might mean! Get into a different mode of thought: the DPAINT files would have ICONS associated with them, all DPAINT would have to do is look at the icons in the folder. Of course, currently, DPAINT doesn't do that and even if it did it would be incompatible with the *new* system, so what I'm really saying here is that with this new workbench there would be standard for finding information. >> (C) Changing DOS would break everything in existance that does funny >> things with the disks, and probably more. > Any change will break something, most likely the somethings that do > 'funny' (read bypass the interfaces) things. You were the one > advocating fixing things before they get cast in concrete. Now > you're shying away from that attitude, precisely when it's needed > the most - at a difficult decision! While C=A is still coming out > with new releases on a regular basis, things can get fixed. And not > all THAT much software is out yet. Sounds like the time is ripe. Changing workbench would break less than Changing DOS's directory structure (though I myself wouldn't mind if C-A changed it for the better). See my discussion on optimizations for DOS that would not change the format on-disk. The jist being that you you could effectively use the current directory hash structure and still get good results, as well as double the speed reading entries. -Matt