[Indigo]Doc>7-27-82.minutes ISSUES DISCUSSED: * a new type of Buttons (Called Nuttons?) * how should we handle aborts? * reorganizing the DBView interface, separating some things out. * reorganizing the Nut interface, breaking it into Nut, Palm, and NutDB. * a new type of Property. * intermixing public and private data bases. NUTTONS Willie-Sue volunteered to check with Scott about a design for Nuttons. Nuttons are Buttons which pass all of the mouse buttons as parameters plus SHIFT and CONTROL, allowing the programmer more flexibility. Thus SHIFT RED could be used to copy the contents of a Button. Nuttons might also include a catch phrase for DB aborts, making button actions atomic. DB ABORTS Rick wanted a uniform way for all client programs to handle DB aborts. Whenever an abort happens, all of the cached state should be automatically recomputed and redisplayed. User actions should be atomic; either they make it into the DB or they don't. Some problems are: How do you make the button actions atomic? How do you get the viewers to redisplay themselves? What about entities that are in the middle of being editted? Suppose the data base changes out from under the user as he issues a command? (The user says "change this" just as the data base aborts, and the user's command is interpreted as applying to the new data base rather than the old, contrary to the user's intentions.) Dave Gifford proposed that the correct message informing the user of a DB abort is: "please wait . . . new data available." PUBLIC vs. PRIVATE DATA BASES Rick brought out a suggestion that there be some way to integrate public (i.e. readonly) and private data bases. There seem to be two axis of data bases: public vs. private and application vs. application. For efficiency the user may want to separate applications from one another. (E.g. Walnut should be separate from everything else). At the same time, you might want to layer a particular application so there is a public, shared data base and a large number of private, personal data bases. Mark may implement a mechanism for this based on segments. There are still a number of questions about how this should appear a) to the programmer and b) to the user of the applications. A NEW SCHEME FOR PROPERTIES The current Schema for DB accesses is confusing because there are two different metaphors presented: Relations and Properties. Many applications (such as Walnut) have to mix these two together because neither is satisfactory by itself. (Properties aren't powerful enough and Relships are too awkward to use). Rick and John discussed some a new type of Prop that is be easy to use and fits in better with the Relship metaphor. This new "Prop" is simply an Attribute. Suppose we define a procedure GetP which takes an Entity and an Attribute and returns a Value (or a LIST OF Value). The procedure would go look for the other Attribute in the relation and find all the Relships with the Entity in this Attribute. It would then return the Value of the first Attribute given. (This only works with the first two attributes of a Relation). Finding the Relation of an Attribute would be fast because Rick caches that information. Finding the other Relation could also be fast if Rick read the cache in the other direction. Then it is just a matter of doing a relation subset to determine the values. One might want to return a generator instead of a LIST of values. The advantage is that the user may not want to enumerate all of the values. The disadvantage is that there is currently no generator for Values. That would make three generators: for Entitys, for Relships, and for Values. One could just have a generator for Values (since Entitys and Relships are also Values) but this would be expensive since you would have to NARROW each value. I propose that we have a separate procedure named GetPList when the programmer expects there to be more than one value. Programs that know that there is exactly one property can use the faster GetP. SetP would overwrite an existing value. SetPList could either append the new values or delete the old ones first. ~~~~~~~~~~~~~~~~~~~~~~~ Jim Donahue proposed that the programmer specify BOTH attributes, rather than have the procedure derive one from the other. His procedure would look like: SetP[attribute1, entity, attribute2, value] where attribute1 would specify where to look for entity and attribute2 would specify where to set value. Rick made a counter proposal that would allow the programmer to default one value if he chose, and to use object oriented notation. His procedure would look like: SetP[entity, attribute2, value, attribute1 _ NIL] => entity.SetP[attribute, value] If someone thought that this was awkward, he could use keyword procedure calls in whatever order he liked. It was also decided that there should be TWO procedures for manipulating property lists, one called ClearList and one called AppendList. Thus the programmer could decide whether he wanted the old values flushed when he set a property list with new values. It was undecided what SetP should do if more than one value was allowed. PROCEDURES SORTED BY CLASS DOMAINS: DeclareDomain DestroyDomain DeclareSubType DestroySubType GetDomainRefAttributes ENTITYS: GetEntity -- create or fetch DestroyEntity GetName SetName Equal Null DomainOf DomainSubset NextEntity ReleaseEntitySubset DomainSetToList GetAllRefAttributes GetP/SetP RELATIONS DeclareRelation DestroyRelation AttributesOf FirstAttributesOf = INLINE AttributesOf[].first (ATTRIBUTES) DeclareAttribute (DestroyAttribute) DeclareIndex GetF/SetF/GetFS/SetFS/(GetFE/SetFE) EntityValued GetType GetUniqueness(String) GetRelation (GetLength) (ATTRIBUTE LISTS) AppendAttributes RemoveAttribute RELSHIPS GetRelship -- create or fetch DestroyRelship RelationOf RelationSubset NextRelship ReleaseRelshipSet RelshipSetToList RsetSize ONE PROC TO FETCH OR CREATE Currently, at the time you program you don't know whether to create an entity or fetch it. Because of this, you have to plan for both possibilities. It would be nice if DBView did this for you. This one procedure would have a version which determined what happens in the different cases: NewOnly: create a new object. If one already exists and multiple objects are prohibited, raise a signal. OldOnly: fetch an old object. If there isn't one, return NIL. NewOrOld: fetch an old object. If none exists, create it. This new procedure could be named "GetX" or "DeclareX". The advantages of "GetX" are that it's shorter to type, and it better matches the functionality its used for. The advantage of "DeclareX" is that all of the schema procedures begin with "Declare". ~~~~~~~~~~~~~~~~~~~~~~~~~ The consensus seemed to be for DeclareX. It was decided that the default version should be NewOrOld, since that is the default everywhere else. It was also decided that if you pass a NIL name, DeclareEntity should GenSym a new name. All of the Declare procedures should be changed to return NIL instead of signalling NotFound. ‌ت(کJکك(Jک—Jکچ Jک—…—ˆ¶