pds@quintus.UUCP (Peter Schachte) (05/11/88)
In article <5920@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > This is David Joiner's (talin @ BIX) posting on BIX regarding Amiga > "resources". [ lots of stuff left out] > I feel it is IMPORTANT that set files be able to store code fragments. > This is because future intuitions will have the ability to have customized > 'handlers' for windows/menus/gadgets, which should be SHARABLE between > applications. Also, programmers should be able to write 'handlers' for their own types of datastructures, e.g., pictures, animations, spreadsheets, etc. I think this omission is one of the biggest flaws of IFF: I can define an IFF form for, say, a spreadsheet, but any application that wants to be able to handle the data has to have my code linked in. What would be really good, and would put the Amiga way in front of the Mac in terms of easy integration of programs is the ability to define abstract datatypes (or call them classes, sets, resources, whatever you like; the important thing is that they include code) that live in some permanent place (DEVS: seems like a reasonable place), are loaded and unloaded as needed, and can be shared between applications. In addition, it is important that programs have some easy way to create instances of these datatypes, read and write them from/to files, display them on screen or printer (where this is appropriate). For example, my word processor ought to be able to copy or paste in ANYTHING that "knows how to" display itself on screen and printer, and read and write itself to a file. And as the writer of the WP, I wouldn't have to know ANYTHING about the thing being inserted. So a user of my WP could buy the latest fancy chart program and include a pie chart it generates in his documents, even though I, as author of the WP, never thought of putting such charts in a document. Sorry if I'm being verbose, and/or stating what everyone else is already thinking. Matt and David, is this where you're heading? Is there anything about what I'm suggesting that is more difficult than what you had in mind? Any gaping flaws? I hope someone who has BIX access will pass this on to David Joiner (Leo?). Thanks. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
thomson@utah-cs.UUCP (Richard A Thomson) (05/11/88)
In article <957@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >In article <5920@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) posts > for David Joiner (talin @ BIX) regarding Amiga "resources". >[ lots of stuff left out] >> future intuitions will have the ability to have customized 'handlers' for >> windows/menus/gadgets, which should be SHARABLE between applications. > > Also, programmers should be able to write 'handlers' for their own types > of datastructures. ... one of the biggest flaws of IFF [is that] any > application that wants the data has to have my code linked in. I agree with you that this modularity is indeed useful and that it is realizable with the Amiga system. I don't understand why you say it is a problem with IFF, though. Sure, IFF is an Interchange File Format, but it isn't intended to transport code. It was designed in a way to give file interchange between not only Amiga applications but all kinds of applications on many different machines. > ... easy > integration of programs is the ability to define abstract datatypes [that] > are loaded and unloaded as needed, and can be shared between applications. BUT, this kind of facility for sharing "data structures + algorithms" already exists on the Amiga. What's wrong with the metaphor of the run-time library as an abstract datatype? For that matter, where's the line between the library and an object under object oriented programming? I always thought the run-time library support of the Amiga was one of the things that made it unique in its respect because of this. Perhaps I should just shut up about it and write my HyperAtlas that works this way. > In addition, it is important that programs have some easy way to create > instances of these datatypes, read and write them from/to files, display > them on screen or printer (where this is appropriate). [ gives examples of why this is a big win ] Well, what I think you're getting into here is this idea of the "standard" things that a library should do. Remember in the library data structure there are a certain, small number of things for which any standard library must provide a routine. The one that comes to mind is Initialize() which sets up the local, hidden data structures needed by the operation of the library routines. >Sorry if I'm being verbose, and/or stating what everyone else is >already thinking. Matt and David, is this where you're heading? Is >there anything about what I'm suggesting that is more difficult than >what you had in mind? Any gaping flaws? At the risk of being verbose, I still see a problem with regards to the implementation of ADTs as a .libary and sharing them among different programs. You'll still have to have some kind of knowledge about the library when writing the program since you must call the routines in the library. If the function vectors are all the same (i.e. a longer list of 'required' functions in the library) for all these object libraries, then no programs will break on attempting to access another library with the same call. Perhaps the way to do a hyper-card like thing is to have a bunch of these object libraries around PLUS an extra library that has all your scripting support routines (Arexx?). Then multiple scripts share the script library, so they are small. Any objects not being used (i.e. the library use count is down to zero, but the library is still hanging around in memory) will be thrown out by Exec. Suggestions anyone? >I hope someone who has BIX access will pass this on to David Joiner >(Leo?). Thanks. I double this sentiment. -- Rich -- USnail: Richard Thomson, Design Engineer, Oasis Technologies, 3190 MEB, University of Utah, Salt Lake City, Utah 84112 ARPA: thomson@cs.utah.edu FONE: (801) 584-4555: Talk to a machine; UUCP: {bellcore, ihnp4, ut-sally}!utah-cs!redpine!thomson they're lonely.
pds@quintus.UUCP (05/13/88)
In article <5483@utah-cs.UUCP>, thomson@utah-cs.UUCP (Richard A Thomson) writes: > I agree with you that this modularity is indeed useful and that it is > realizable with the Amiga system. I don't understand why you say it is a > problem with IFF, though. Sure, IFF is an Interchange File Format, but it > isn't intended to transport code. It was designed in a way to give file > interchange between not only Amiga applications but all kinds of applications > on many different machines. ... > What's wrong with the metaphor of the run-time library > as an abstract datatype? For that matter, where's the line between the library > and an object under object oriented programming? A library can indeed serve as an implementation of a class (or datatype). I believe this would work very well. But there are a few things missing. What's missing is the SYSTEM. The conventions. There needs to be a few routines (probably in a library, to keep them shared) to do things like create an object and read an object from a file or buffer. Operations where you don't have an object to operate on yet. Also needed is a set of rules about coding this way. Common operations should all be at the same offset in the library (if libraries are indeed used to implement this stuff). If this thing is to include inheritance, then a mechanism for implementing it must be coded. It may not be a great deal of code, but some is required. More importantly, a careful design is needed. > At the risk of being verbose, I still see a problem with regards to the > implementation of ADTs as a .libary and sharing them among different programs. > You'll still have to have some kind of knowledge about the library when > writing the program since you must call the routines in the library. That's the role of the system. One way to do it would be to have each .library somehow include the list of operations it supports and the function vector offset for each. The .library would register this info with the system (let's call it Abstract Data Type System, or ADTS) in it's initialization code. Let's say that the first longword of each instance (object) in memory would uniquely determine the type (class) of the instance (a la IFF). When a message is to be sent to an object, the message name would be a string, which the ADTS would turn into a library function vector offset. If you want inheritance, that's not too hard, either. When a .library is registering itself with the ADTS, it would say that it's a subclass of some other class (whose library would then be loaded). The ADTS would then give this .library all the methods of the parent (except those it defines itself). Not too hard. It just requires that the ADTS record the library base, as well as the offset, for each class/message name pair. (Otherwise you could just store the offset for each pair, and the base once for the datatype.) There are some other wonderful things this could bring, but I'll discuss them in another posting. It would be nice to be able to have a single mapping of method name -> function vector offset. I'm afraid, though, that since the offsets are determined at the time the library is constructed, that will not be possible. Anybody have a way around this problem? > Perhaps the way to do a hyper-card like thing is to have a bunch of these > object libraries around PLUS an extra library that has all your scripting > support routines (Arexx?). Then multiple scripts share the script library, > so they are small. Any objects not being used (i.e. the library use count > is down to zero, but the library is still hanging around in memory) will > be thrown out by Exec. Suggestions anyone? Seems reasonable. It might be better, though, to define "hypermedia" as a class, which would (eventually) have lots of subclasses. I think, as I said earlier, that such a system, if adopted as a standard and blessed, like IFF, would make the Amiga the best-integrated system going. It would capitalize on one of the features of the Amiga that even Unix systems haven't caught up with yet: shared libraries. But in order for this to happen, it MUST be blessed. So I hope people that are interested in this sort of thing (Matt? David?) can get together and agree on an approach, and that CA can get involved at some point. Leo? You still there? Could you (or anyone with BIX access) please pass this on to David Joiner again? Thanks. (Why isn't there a BIX gateway?) -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
guilford@sunlight.steinmetz (jim guilford) (05/18/88)
In article <5483@utah-cs.UUCP> thomson@cs.utah.edu.UUCP (Richard A Thomson) writes: >In article <957@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >>In article <5920@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) posts >> for David Joiner (talin @ BIX) regarding Amiga "resources". >> >> Also, programmers should be able to write 'handlers' for their own types >> of datastructures. ... one of the biggest flaws of IFF [is that] any >> application that wants the data has to have my code linked in. > > >BUT, this kind of facility for sharing "data structures + algorithms" already >exists on the Amiga. What's wrong with the metaphor of the run-time library >as an abstract datatype? For that matter, where's the line between the library >and an object under object oriented programming? > > >Well, what I think you're getting into here is this idea of the "standard" >things that a library should do. Remember in the library data structure there >are a certain, small number of things for which any standard library must >provide a routine. The one that comes to mind is Initialize() which sets >up the local, hidden data structures needed by the operation of the library >routines. > >If the function vectors are all the same (i.e. a longer list of 'required' >functions in the library) for all these object libraries, then no programs >will break on attempting to access another library with the same call. > > -- Rich >-- >USnail: Richard Thomson, Design Engineer, Oasis Technologies, 3190 MEB, > University of Utah, Salt Lake City, Utah 84112 >ARPA: thomson@cs.utah.edu FONE: (801) 584-4555: Talk to a machine; >UUCP: {bellcore, ihnp4, ut-sally}!utah-cs!redpine!thomson they're lonely. It seems to me that libraries can very easily provide many of the features of ADTs. It would be nice to take an editor, and add a graphic object to it. The editor would not have to know anything about the object, except that it had a minimum set of commands that it understood. Then in order to add a new object all one would need to do to add a new object is to write an appropriate library and tell the editor where it is. Instantly, your drawing probram now understands pie charts (e.g.). I would have problems with making a huge list of 'reguired' commands to be added to the library vectors. The sort of commands one would need are so diverse, that the list would be huge. I would suggest the following: you add one reguired function to the library vector. This would be a name mapper. When one first loaded the library (ADT), one would pass the mapper a string for each command you expected it to have. The mapper (who knows what is actually in the library) would pass back the address of the function which implements it (or NULL if it is not implemented). Thereafter (since the library can not move within memory), the user program would just call the pointer to the function. There would have to be some degree of standardization for the names used for functions (e.g. 'create' 'new' 'make'?) so that different programs can use the same ADTs, but that is another issue. In this way, one would not have to create stubs for many unsupported functions and worry about conflicting with others when you need to add new functions. Given a sufficiently verbose string, the chance of collisions would be small. The program would not need to know anything of the structure of the library (besides where the mapper lived), although the library would need to know the names of the functions needed. Additionally, one could build an ADT on top of another. This would be nothing more than having one library call another. It could intercept certain calls, possibly pass them through, or possibly ignore them. If it chose to ignore a function, its mapper would call the mapper of the function it was based on, and return that value. Then any calls to that function would go directly to whoever handles it. The main implementational problem is getting a nice way to make libraries out of code (and possibly a way to automagically generate the mapper code). The main functional problem I see with this approach, is that the user has to know what type an object is in order to call the proper routine. I can not write a handler to deal with a generic object. This could be handled in the following way. When each ADT is loaded, an initialization function is called with a pointer to a global data structure. This contains (among other things) a counter, so that each ADT is given a unique small integer id. Then when the mapper is called, it returns instead of a pointer, a unique small integer value. The global data structure has an array of descriptors for each ADT each containing an array of pointers to functions. Each instance of an ADT has at the beginning of it the small integer id value for that ADT. Then when anyone wants to perform a function on an ADT (send it a message?), one calls a router routine with the object, the id of the operation, and the parameters needed. The router looks the ADT-id and operation-id up in its tables and branches to the appropriate routine. The reason I want to map strings into small integers is to avoid having to do a string based table search on each function call, and at the same time keep long descriptive names (sharing numbers between many applications just doesn't work). It seems to me that this would provide all of the useful features of dynamically loadable ADTs. What do people think? Could this work? Are there problems with it or changes that would need to be made? Would this be a useful system or would it just sit on the side and gather dust? --JimG guilford@turning.cs.rpi.edu guilford@csv.rpi.edu ....!rutgers!nysernic!rpics!guilford --------
jesup@cbmvax.UUCP (05/19/88)
In article <10881@steinmetz.ge.com> guilford@turing.cs.rpi.edu (Jim Guilford) writes: > I would suggest the >following: you add one reguired function to the library vector. This >would be a name mapper. When one first loaded the library (ADT), one >would pass the mapper a string for each command you expected it to >have. The mapper (who knows what is actually in the library) would >pass back the address of the function which implements it (or NULL if >it is not implemented). Jim: You've just re-invented the Sun RPC protocol. Get a copy of the SUN RPC RFC (don't you love acronyms?), Ray Brand has it. In terms of name mappers: Mine is currently still under way, posting of the current user.doc and mapperbase.h will occur in the next few days. It could be used to prevent having inumerable different name mappers. >--JimG Randell Jesup {uunet|ihnp4|allegra}!cbmvax!jesup