Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!eric!joplin!ssmith From: ssmith@joplin.mpr.ca (Shaun Smith) Newsgroups: comp.object Subject: Re: Persistent Objects Was: Re: Pre-computing objects Summary: The problem is perceiving a difference between memory and disk storage. Keywords: persistent objects, REKURSIV, storage devices Message-ID: <1852@eric.mpr.ca> Date: 27 Oct 89 18:19:42 GMT References: <4671be53.20b6d@apollo.HP.COM> <4908@internal.Apple.COM> Sender: news@eric.mpr.ca Reply-To: ssmith@joplin.UUCP (Shaun Smith) Organization: Microtel Pacific Research Ltd., Burnaby, B.C., Canada Lines: 42 Since a discussion of persistent objects has sprung up I thought I'd bring up the REKURSIV chip set (VME board/computer) again. I had previously posted to comp.lang.smalltalk and comp.arch to ask whether anyone had any experience with the REKURSIV. Well, now that we have comp.object, which is probably the best place to ask that question, I'll ask it again. Would those having experience with REKURSIV like to tell us about what it's like to have a machine built from the ground up to support object-oriented programming? (the REKURSIV design is itself object-oriented, the memory manager and the cpu communicate via "messages" and memory is composed of objects, not blocks of bytes). Having said that, let me know explain what this has to do with persistent objects. The REKURSIV has _NO_ concept of temporary vs. permanent storage. That is, the concept of files does not exist. David Harland (primary architect) argues in his book that computer users should not have to deal with the problem of converting an arbitrary object into a byte stream that can be placed on permanent storage. REKURSIV's approach is to swap out objects that are not in use and keep in memory objects that are. It does not swap pages, but rather swaps individual object. The root of Harland's argument is that users should not have to think in terms of different types of storage at all. "Storage" should be seen as "Storage" and things (programs, databases, objects) should persist until disposed of. The way in which they persist should not have to be an issue for the user, they just persist. In this way, all objects are persistent. They just hang around on disk until you need them or destroy them. (This does not mean that there isn't garbage collection). This is not exactly a general solution, but it is interesting. Shaun Shaun M. Smith | ssmith@joplin.mpr.ca Microtel Pacific Research | joplin.mpr.ca!ssmith@uunet.uu.net 8999 Nelson Way, Burnaby, BC | ssmith%joplin.mpr.ca@relay.ubc.ca Canada, V5A 4B5, (604) 293-5345 | ...!ubc-vision!joplinmpr.ca!ssmith