Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!udel!rochester!kodak!ispd-newsserver!ph From: ph@ssd.kodak.com (Pete Hoch) Newsgroups: comp.sys.mac.programmer Subject: Re: Is there a defacto standard for 'drop ins'? Message-ID: <1991Mar27.204705.5725@ssd.kodak.com> Date: 27 Mar 91 20:47:05 GMT References: <13180@adobe.UUCP> <13225@adobe.UUCP> Sender: news@ssd.kodak.com Organization: Eastman Kodak Lines: 45 In article <13225@adobe.UUCP> hawley@adobe.UUCP (Steve Hawley) writes: > If I write a terminal emulator and decide that I want to allow drop > in modules for transfer protocol or emulation, I'm probably going to > want to use stream IO. If I write something like PhotoShop, I'd > probably want block IO (in fact, I'd probably rather have > the pointer to a data structure). How about if we go one further and instead of a pointer to a data structure we define a whole object. The data object would need methods for data access to override, but the actual data storage etc, would be left up to the subclass. Apple has been claiming for almost two years now that objects are the way to go. Prehaps this is the time to design a filter manager that coordinates the instilation of filter objects. (Are you listening CTB developers?) >The important point (do I really have to type this for the third time?) which >is the answer to the original question of "why is there no standard means of >doing drop-in modules" is that there is no standard task that needs to be done >by a drop-in module. The needs are different, so therefore are the means of >satisfying that need. Perhaps my original question was based at too low a level. Let me refraze. I have noticed the use of 'drop in' code in more and more application. Examples of this are Photoshop, Stuffit, and the comm toolbox. All of these have their own way of selecting the 'drop in' code from the users point of view. And each had to impliment a method for loading and exicuting the `drop ins`. So what I was really thinking, (if not specificly asking) was, can there and *should there* be a high level filter manager that regardless of functionality will provide the user with a consistent way of dealing with 'drop ins'? >I realy didn't mean for this to get into so much "block IO! Nyah! stream IO! >Nyah!" traffic. Really. Me either. Pete -- Pete Hoch | ..somewhere..!kodak!ssd!bashow!ph ..or.. Color Systems ISPD. 3/65/RL | ph@ekcolorlink.ssd.kodak.com ..or.. Eastman Kodak Co. | ph@bashow.ssd.kodak.com Rochester, NY 14650-1805 | 716-722-3285