home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / object / 5026 < prev    next >
Encoding:
Text File  |  1993-01-23  |  59.3 KB  |  1,677 lines

  1. Newsgroups: comp.object
  2. Path: sparky!uunet!charon.amdahl.com!netcomsv!netcom.com!objsys
  3. From: Bob Hathaway <objsys@netcom.com>
  4. Subject: FAQ (Part 2 of 2)
  5. Message-ID: <1993Jan23.071143.249@netcom.com>
  6. Keywords: FAQ
  7. Sender: objsys@netcom.com (Object Systems)
  8. Organization: Object Systems
  9. Date: Sat, 23 Jan 1993 07:11:43 GMT
  10. Lines: 1665
  11.  
  12.  
  13. APPENDICES
  14. ==========
  15.  
  16. APPENDIX A  VIPS
  17. ================
  18.  
  19. These are individuals whose names appear in comp.object most often. 
  20. Please send recommendations for *major* VIPS often cited or referenced.
  21.  
  22. Booch, Grady
  23.  
  24. Grady Booch has been an object-oriented Ada advocate for some time.  He's
  25. written books such as Software Engineering with Ada, Software Components
  26. with Ada, and OOD with Applications.  The first two are what he calls
  27. Object-Based and the second is primarily Object-Oriented and all use
  28. OB and OO notations and methodologies.  His last notations are often
  29. referred to as simply the "Booch" method or notation and his company,
  30. Rational, provides automated support with a tool named "Rose".
  31.  
  32. Goldberg, Adele
  33.  
  34. One of the founders of Smalltalk.  David Robson is another.  They are most
  35. well know because of their text, "Smalltalk-80 The Language and its
  36. Implementation".  Smalltalk was invented by a group at Xerox PARC.
  37.  
  38. Meyer, Bertrand
  39.  
  40. Founder of Eiffel, author of [Meyer 88].  Often posts to comp.lang.eiffel
  41. [what a FAQ writer notices].
  42.  
  43. Nygaard, krysten and Dahl, Ole-Johan.
  44.  
  45. Inventor of Simula, the first object-oriented programming language.
  46.  
  47. Rumbaugh, James
  48.  
  49. Part of Rumbaugh, Blaha, Premerlani, Eddy and Lorenson, The authors of
  50. [Rumbaugh 91].  They are from GE's R&D Center and Have an OOA/OOD
  51. notation/Methodology called the "Object Modeling Technique".  It is a rather
  52. formal and complete method which is often discussed and referred to.  OMTool
  53. is the name of the CASE system provided by GE which supports OMT.
  54.  
  55. Shlaer, Sally (and Mellor, Stephen J.)
  56. >Sally Shlaer            sally@projtech.com
  57. >Project Technology      Training and Consulting using Shlaer-Mellor OOA/RD
  58. >Berkeley, CA            (510) 845 1484
  59.  
  60. Founder of the Shlaer/Mellor OOA/RD method.  As shown above, occasionally
  61. posts to comp.object [what a FAQ writer notices].
  62.  
  63. Stroustrup, Bjarne
  64.  
  65. Inventor of C++, a C superset, which has probably gained the most widespread
  66. use of any object-oriented language today.
  67.  
  68.  
  69. APPENDIX B  Object-Oriented Databases and Vendors
  70. =================================================
  71.  
  72. This is an initial list of Object-Oriented databases.  Thanks go to Stewart
  73. Clamen, who Ok'd the use of his survey.  His survey is actually on schema
  74. evolution in OODB's, but it covers so many systems it should do for a start.
  75. Additional short entries are encouraged; please send additions to the author
  76. of the FAQ (and/or to Stewart).  Also, I noticed [Kim 89] covers a few of
  77. the research systems below in depth.
  78.  
  79. Entries will be more well-rounded in future (non-draft) FAQs.
  80.  
  81.  
  82. From: Stewart M. Clamen <clamen@cs.cmu.edu>
  83.  
  84.  The most recent copy of this summary will be available indefinitely
  85.  via anonymous FTP from BYRON.SP.CS.CMU.EDU:clamen/evolution-summary.
  86.  
  87. Last update: 14Oct92
  88.  
  89. Direct quotes are attributed by including the email address of the
  90. poster directly following the information.  Prose written by the
  91. poster, but with primary information provided by email are so
  92. identified.  Information gleaned from publications is so noted.  The
  93. information included here is not intended to completely describe the
  94. systems addressed, but rather, to describe what support, if any, is
  95. provided by the system for the evolution of schemas and the conversion
  96. of database objects (class instances) resulting from the schema
  97. change.
  98.  
  99.                                                         Stewart Clamen
  100.  
  101.                        ----------*-*----------
  102.  
  103.                           TABLE OF CONTENTS
  104.  
  105.  
  106. Extended Relational Database Model
  107.  Research Systems
  108.   POSTGRES
  109.  
  110. Object-Oriented Data Model
  111.  Research Systems
  112.   AVANCE
  113.   ConceptBase
  114.   CLOSQL
  115.   COOL/COCOON
  116.   Encore
  117.   Exodus
  118.   Machiavelli
  119.   OBST/STONE
  120.   Orion [marketed as Itasca]
  121.   OTGen
  122.  
  123. Commercial Systems
  124.   Common Lisp Object System (CLOS)
  125.   EasyDB (Objective Systems, Sweden)
  126.   GemStone
  127.   O_2
  128.   Objectivity/DB
  129.   ObjectStore
  130.   Ontos [formerly VBase]
  131.   Statice
  132.   Versant
  133.  
  134. Other Models
  135.  Research Systems  
  136.   IRIS
  137.  Commercial Systems  
  138.   IDL
  139.   Kala
  140.   Pick
  141.  
  142.  
  143.                        ----------*-*----------
  144.  
  145.  
  146.                  <<< EXTENDED RELATIONAL DB MODEL >>>
  147.  
  148.                         << Research Systems >>
  149.  
  150.  
  151. >> POSTGRES (Berkeley)
  152.  
  153. You ask explicitly about type evolution.  We support schema
  154. modification on all classes, including user classes.  This means that
  155. you can add attributes (instance slots) and methods at any time.
  156. Further, since postgres is a shared database system, such changes are
  157. instantly visible to any other user of the class.
  158.  
  159. The language syntax supports attribute deletion, but the system won't
  160. do it yet.  Since all data is persistent, removing attributes from a
  161. class requires some work -- you need to either get rid of or ignore
  162. all the values you've already stored.
  163.  
  164. [Mike Olson <mao@Postgres.Berkeley.EDU>]
  165.  
  166.  
  167.  
  168.                         <<< OO DATA MODEL >>>
  169.  
  170.                         << Research Systems >>
  171.  
  172. >> AVANCE (SYSLAB)
  173.  
  174. An object-oriented, distributed database programming language.  Its
  175. most interesting feature is the presence of system-level version
  176. control, which is used to support schema evolution, system-level
  177. versioning (as a way of improving concurrency), and objects with their
  178. own notion of history.  System consists of programming language (PAL)
  179. and distributed persistent object manager. 
  180.  
  181. REFERENCES: 
  182.         Anders Bjornerstedt and Stefan Britts. "AVANCE: An
  183.         Object Management System".  Proceedings of OOPSLA88.
  184.  
  185. [clamen]
  186.  
  187.  
  188.  
  189. >> CLOSQL (University of Lancaster)
  190.  
  191. CLOSQL is a prototype object environment written on top of CLOS [c.f.
  192. CLtL II].  CLOSQL implements a class versioning scheme (like ENCORE),
  193. but employs a conversion adaptation strategy.  Instances are converted
  194. when there is a version conflict, but unlike ORION and GemStone,
  195. CLOSQL can convert instances to older versions of the class if
  196. necessary.
  197.  
  198.  
  199. REFERENCES: 
  200.  
  201.         Simon Monk and Ian Sommerville. "A Model for Versioning
  202.         Classes in Object-Oriented Databases."  Proceedings of the
  203.         Tenth British National Conference on Databases (BNCOD10).
  204.         Aberdeen, Scotland. July, 1992.
  205.  
  206. [clamen, srm@computing.lancaster.ac.uk]
  207.  
  208.  
  209.  
  210. >> ConceptBase
  211.  
  212. We have developed a deductive object-oriented database called
  213. ConceptBase where everything (tokens, classes, meta-classes
  214. ,meta-meta-classes ,attributes, instantiations, specializations) is
  215. treated as an object. That means that you may update the "schema"
  216. (classes) at any time just as any other ordinary object.
  217.  
  218. The systems has (user-defined and builtin) integrity constraints that
  219. prevent inconsistency (e.g. violation of ref.integrity).  Integrity
  220. constraints in ConceptBase are (as in most other systems) static,
  221. i.e., they are conditions that each database "state" must satisfy.
  222.  
  223. The data model we use does not distinguish schema level information
  224. (i.e. classes) from instance level information. If you change for
  225. example some classes and this change violates some integrity
  226. constraints, e.g.  some instances now don't have the right attribute
  227. types anymore, then you have the choice either to reject the update or
  228. to change the existing DB. Currently, ConceptBase simply rejects such
  229. updates.  We are thinking of exploiting abduction (see VLDB'90 article
  230. of Kakas&Mancarella) to make more clever reactions in the sense of
  231. "reformating" instances.
  232.  
  233. The system is available for research purposes. Contact
  234.  
  235.                  CB@picasso.informatik.rwth-aachen.de
  236.  
  237. for more information.
  238.  
  239.  
  240. [Manfred Jeusfeld <jeusfeld@forwiss.uni-passau.de>]
  241.  
  242.  
  243.  
  244. >> COOL/COCOON (Ulm Universitaet)
  245.  
  246. Project goals are:
  247.  
  248. - to develop a general formal framework for investigations of all
  249.   kinds of schema changes in object-oriented database systems
  250.   (including schema design, schema modification, schema tailoring, and
  251.   schema integration);
  252. - to find implementation techniques for evolving database schemas,
  253.   such that changes on the logical level propagate automatically to
  254.   adaptations of the physical level (without the need to modify all
  255.   instances, if possible).
  256.  
  257.  
  258. In their current paper [see below], schema evolution is used as
  259. example of a general framework for change in OODBs, supporting change
  260. on three levels of database objects: data objects, schema objects, and
  261. meta-schema objects.
  262.  
  263.  
  264. Contact Markus Tresch <tresch@informatik.uni-ulm.de> for more information.
  265.  
  266.  
  267. REFERENCES:
  268.         M. Tresch and M.H. Scholl. "Meta Object Management
  269.         and its Application to Database Evolution."  In
  270.         _Proceedings of the Eleventh International
  271.         Conference on the Entity-Relationship Approach",
  272.         Karlsruhe, Germany, Oct 1992.  Springer Verlag (to
  273.         appear).
  274.  
  275.  
  276.  
  277. >> Encore (Brown University)
  278.  
  279. Objects are never converted, rather, classes are versioned, and the
  280. user can specify filters to make old-style instances appear as new
  281. instances to new applications (and vice versa).
  282.  
  283. REFERENCES:
  284.         Andrea H. Skarra,  and Stanley B. Zdonik. "Type
  285.         Evolution in an Object-Oriented Database."  In the
  286.         book, "Research Directions in Object-Oriented
  287.         Programming", by Shriver and Wegner.  (An earlier
  288.         version of the paper appears in the proceedings to
  289.         OOPSLA86.) 
  290.  
  291. [clamen]
  292.  
  293.  
  294.  
  295. >> Exodus (University of Wisconsin)
  296.  
  297. No solution for the problem of schema evolution is provided.
  298. Emulation is rejected by the authors, who claim that the addition of a
  299. layer between the EXODUS Storage Manager and the E program would
  300. seriously reduce efficiency.  Automatic conversion, whether lazy or
  301. eager, is also rejected, as it does not mesh well with the C++ data
  302. layout.  To implement immediate references to other classes and
  303. structures, C++ embeds class and structure instances within its
  304. referent.  The resulting change in the size of the object might
  305. invalidate remote pointer references.
  306.  
  307.         Joel E.  Richardson and Michael J.  Carey.  "Persistence
  308.         in the E language: Issues and Implementation."  Appeared
  309.         in "Software -- Practice and Experience",
  310.         19(12):1115-1150, December 1989.
  311.  
  312. [clamen]
  313.  
  314.  
  315. >> Machiavelli (University of Pennsylvania)
  316.  
  317. Machiavelli is a statically-typed programming language developed
  318. at the University of Pennsylvania. Its most outstanding innovation 
  319. is the use of conditional typing scheme in its type inference system. 
  320. It does not address type evolution.
  321.  
  322. [communication with limsoon@saul.cis.upenn.edu]
  323.  
  324. [Ed. Note: Machiavelli is included in this summary because it
  325.            previously incorporated persistence in its data model.]
  326.  
  327.  
  328.  
  329. >> OBST/STONE (Forschungszentrum Informatik [FZI], Karlsruhe, Germany)
  330.  
  331. The currently available version of OBST (3.2) does not provide any
  332. support for schema evolution. Users may modify the meta database to
  333. adapt the schema information to their changed needs, but they do so on
  334. their own risk and without any support. Existing instances are not
  335. adapted automatically.
  336.  
  337. A new release of OBST is planned for the end of this year.  This
  338. version will provide a new meta schema, with some operations to make
  339. schema modifications more comfortable.
  340.  
  341. Furthermore we work at the moment on:
  342.  
  343.    -  a graphical schema browser that will make schema design 
  344.       and modification more fun
  345.  
  346.    -  a view concept that shall make OBST applications to a wide
  347.       degree independent from schema changes
  348.  
  349.    -  an integration of different conversion strategies (immediate
  350.       conversion, different kinds of lazy conversion and screening),
  351.       to provide suitable mechanisms for all situations during the
  352.       schema life cycle
  353.  
  354. The first two developments shall be available with new OBST releases
  355. during the first half of 1993.
  356.  
  357. While the two points mentioned above are already to be implemented,
  358. the last point is just in an experimental state, and matter of
  359. investigation.
  360.  
  361.  
  362. [schiefer@fzi.de]
  363.  
  364.  
  365. The system is available by anonymous FTP from GATE.FZI.DE. Contact
  366. stone@fzi.de for more information.
  367.  
  368.  
  369.  
  370. >> ORION [now Itasca] (MCC/Itasca System, Inc.)
  371.  
  372. ORION was a prototype OODBMS developed at MCC, an American consortium.
  373. It is now marketed as Itasca by Itasca Systems in Minnesota.  ORION is
  374. built on top of Common Lisp, and is intended to support applications
  375. such in the CAD/CAM, AI, and OIS domains.  Advanced functions
  376. supported include [object] versions, change notification, composite
  377. objects, dynamic schema evolution, and multimedia data.
  378.  
  379. For schema evolution, ORION identifies a list of database-consistency
  380. constraints that must be preserved across any class evolution
  381. operation.  They then list the type of evolution operations you can
  382. perform, and how the relevant instances can be converted.  Conversion
  383. is performed as the instances are accessed.
  384.  
  385. REFERENCES:
  386.  
  387. I have found nearly a dozen papers published by the ORION folks.  The
  388. most recent and general one is:
  389.  
  390.         W. Kim, N. Ballow, H-T. Chou, J.F. Garza, D. Woelk,
  391.         and J.  Banerjee. "Integrating an Object-Oriented
  392.         Programming System with a Database System."
  393.         Proceedings of OOPSLA88.  [Pointers to the previous
  394.         papers documenting each of the advanced features
  395.         listed above are cited therein.]
  396.  
  397. The paper most relevant to the issue of schema evolution is the
  398. following:
  399.  
  400.         J. Banerjee, W. Kim, H.J. Kim, H.F. Korth.
  401.         "Semantics and Implementation of Schema Evolution in
  402.         Object-Oriented Databases." Proceedings of SIGMOD87.
  403.  
  404. You might also like to look at Kim's book:
  405.  
  406.         Won Kim.  _Introduction to Object-Oriented
  407.         Databases_. MIT Press, Cambridge, Mass., 1990.
  408.  
  409. [clamen]
  410.  
  411.  
  412.  
  413. >> OTGen (Carnegie Mellon University/UMass Amherst)
  414.  
  415. OTGen describes a scheme for computer-assisted schema evolution.  A
  416. wide variety of changes (wider than those supported by Orion or
  417. GemStone) can be expressed in the evolution "mini-language", which
  418. describes a procedure for transforming instances from their new to old
  419. representations.  Objects are converted as databases (which in the
  420. invisioned OTGen system are rather small) are opened.
  421.  
  422. REFERENCES:
  423.  
  424.         Barbara Staudt Lerner and A. Nico Habermann. "Beyond
  425.         Schema Evolution to Database Reorganization" in
  426.         Proceedings of OOPSLA/ECOOP '90.
  427.  
  428. [clamen, blerner@cs.umass.edu]
  429.  
  430.  
  431.                        << Commercial Systems >>
  432.  
  433. >> Common Lisp Object System
  434.  
  435. Not persistent, but implementations must support redefinition of
  436. classes and the conversion (either lazy or eager) of existing
  437. instances. [c.f. CLtL II]  In spite of this freedom, implementations
  438. seem to convert lazily.
  439. [communication with gregor@parc.xerox.com, hornig@symbolics.com,
  440.  dussud@lucid.com] 
  441.  
  442. The generic function UPDATE-INSTANCE-FOR-REDEFINED-CLASS discards old
  443. slots (and the values of redefined slots).  However, the generic can
  444. be overriden by the user, allowing for arbitary instance conversion
  445. procedures.
  446.  
  447.  
  448. REFERENCES:
  449.  
  450. [CLtL II]       Steele, Jr., Guy L.  _Common Lisp: The Language_.
  451.                 Second Edition.  Digital Press.  1990.
  452.         
  453.  
  454.  
  455. >> EasyDB (Objective Systems, Sweden)
  456.  
  457. EasyDB features a (programming language independent) Data Definition
  458. Language (DDL) for the definition of schemas.  It relies on the
  459. Entity-Attribute-Relationship model.  Data Manipulation Languages
  460. (DML) include a Navigational Query language (NQL) embedded in a host
  461. language (C available now, Ada in January '93), and a generic C++
  462. class library.
  463.  
  464. The schema may be freely extended with new items (types, domains,
  465. attributes, entities, relationships etc.). Deletion of items is not
  466. allowed.
  467.  
  468. Data created with an older schema may co-exist with newer data. Old
  469. applications need not be recompiled when the schema is updated.
  470. Attempts by newer applications to access `older' data in an
  471. inconsistent way are detected and reported via an exception handling
  472. system.
  473.  
  474. [Tomas Lundstrom <tomas@os.se>]
  475.  
  476.  
  477.  
  478. >> GemStone (Servio Logic)
  479.  
  480. GemStone currently supports modification of leaf classes (classes with
  481. no subclasses) with transparent, lazy, data migration.  Immediate
  482. migration can also be forced.  Modification of non-leaf classes is
  483. also possible, but requires some programming in GemStone's DML to make
  484. it happen.  Transparent migration of modified non-leaf classes will be
  485. offered in a future release.
  486.  
  487. [Bruce Schuchardt <bruce@slc.com>]
  488.  
  489.  
  490. ADDITIONAL REFERENCES: 
  491.         Robert Bretl, David Maier, Allan Otis, Jason Penney,
  492.         Bruce Schuchardt, Jacob Stein, E. Harold Williams,
  493.         Monty Williams. "The GemStone Data Management
  494.         System."  Chapter 12 of "Object-Oriented Concepts,
  495.         Databases and Applications", by Kim and Lockovsky.
  496.  
  497.  
  498.  
  499. >> O_2 (INRIA/O_2 Technology)
  500.  
  501. We have implemented in O2 schema updates in our first release but
  502. without NO IMPACT on the database (we have a design to implement
  503. deferred update, but it is a paper design). However, users manage to
  504. convert their instances by hand, using their O_2 programs written
  505. themselves, and with the aid of the following tools:
  506.  
  507. 1- There is a set of predefined classes whose instances contain
  508.    objects representing a schema (i.e., a Meta-schema). These classes
  509.    may be used in a conversion program, they may even be extended by
  510.    the programmer.
  511.  
  512. 2- There is a save-restore program that allows to take an O2 database,
  513.    save it on a file or a tape in a logical way (i.e., independent of
  514.    the physical format of objects on disk), and restore it again on a
  515.    (perhaps new release) of the system, in an empty database.
  516.    Currently, when saving a database its schema is also saved. The
  517.    next extension to this save/restore program will be to save the
  518.    database without saving its schema, and then restore the database
  519.    on a new version of that schema. The restore program will be able
  520.    to perform automatically some conversions like "add attribute" or
  521.    "delete attribute".
  522.  
  523.  
  524. Schema updates with impact on the database will be implemented in future 
  525. releases.
  526.  
  527. [Fernando Velez <fernando@o2tech.fr>]
  528.  
  529.  
  530. For more information on O_2, consult the following REFERENCES:
  531.  
  532.         Francois Bancilhon, Claude Delobel, Paris
  533.         Kanellakis.  "Building an Object-Oriented Database
  534.         System: The Story of O_2".  Morgan Kaufmann Series
  535.         in Data Management Systems, San Mateo, Calif., 1992.
  536.         
  537.         F. Bancilhon, G. Barbette, V. Benzaken, C. Delobel,
  538.         S. Gamerman, C. Lecluse, P. Pfeffer, P. Richard,
  539.         and F. Velez.  "The Design and Implementation of
  540.         O2, and Object-Oriented Database System".
  541.         Advances in Object-Oriented Database Systems,
  542.         Springer Verlag. (Lecture Notes in Computer Science
  543.         series, Number 334.)
  544.  
  545.         C. Lecluse, P. Richard, and F. Velez. "O2, an
  546.         Object-Oriented Data Model".  Proceedings of
  547.         SIGMOD88.  Also appears in Zdonik and Maier,
  548.         "Readings in Object-Oriented Database Systems",
  549.         Morgan Kaufmann, 1990.
  550.  
  551.  
  552.  
  553.  
  554. >> Objectivity/DB (Objectivity)
  555.  
  556. In the just-released Version 2.0 (shipping Oct 92), schema evolution
  557. is supported via dynamic versioning of type-defining objects [ie.
  558. class versions -- SMC], and via a step-by-step approach that allows
  559. conversion of instance data via user-provided conversion methods.
  560. Also, a full dynamic type manager interface is available for doing
  561. fancier things.
  562.  
  563. [Drew Wade <drew@objy.com>]
  564.  
  565.  
  566.  
  567.  
  568. >> ObjectStore (Object Design)
  569.  
  570.  
  571. ObjectStore does not provide schema evolution as yet but it has
  572. promised to provide schema evolution in the next release.
  573. [h.subramanian@trl.OZ.AU]
  574.  
  575.  
  576. ObjectStore is an ODBMS produced by Object Design, Inc.  Release 2,
  577. which is in beta test now, supports schema evolution.  The kinds of
  578. evolution supported include change of a data member's type, addition
  579. and removal of data members, and change in inheritance structure.
  580. There are default transformations built in, (e.g. from int to float),
  581. and user-defined transformations may be run also.
  582.  
  583. [Jack Orenstein, Object Design, Inc. <jack@odi.com>]
  584.  
  585.  
  586.         
  587. >> Ontos [formerly VBase] (Ontologic)
  588.  
  589. *Ontos provides schema evolution. It allows any class to be modified.
  590. *The major drawback is that data does not migrate ie., instances are
  591. *not modified to adopt to the new class definition. So schema changes
  592. *can be done only on classes that do not contain instances and do not
  593. *have sub classes that contain instances.
  594. *[h.subramanian@trl.OZ.AU]
  595.  
  596. *As a system for experiments, we are currently using ONTOS from
  597. *Ontologic Inc.  Unfortunately, there is no transparent concept of
  598. *schema evolution for populated database. Thus, we still investigate
  599. *how it works.
  600. *[Markus Tresch <tresch@inf.ethz.ch>]
  601.                                    
  602.  
  603.  
  604. >> Statice (Symbolics)
  605.  
  606. I'm familiar with Statice, sold by Symbolics Inc.  The Statice command
  607. "Update Database Schema" brings an existing database into conformance
  608. with a modified schema.  Changes are classified as either compatible
  609. (lossless, i.e., completely information-preserving) or incompatible
  610. (i.e., potentially information-losing in the current implementation).
  611. Basically, any change is compatible except for the following:
  612.  
  613.     -- If an attribute's type changes, all such attributes extant
  614.     are re-initialized (nulled out).  Note that Statice permits
  615.     an attribute to be of type T, the universal type.  Such an
  616.     attribute can then take on any value without schema
  617.     modification or information loss.
  618.  
  619.     -- If a type's inheritance (list of parents) changes, the
  620.     type must be deleted and re-created, losing all extant
  621.     instances of that type. This is Statice's most serious
  622.     current limitation.  The simplest workaround is to employ a
  623.     database dumper/loader (either the one supplied by Symbolics
  624.     or a customized one) to save the information elements and
  625.     then reload them into the modified schema.
  626.  
  627. [Lawrence G Mayka <lgm@IExist.ATT.COM>]
  628.  
  629.  
  630.  
  631. >> Versant (Versant Object Technology)
  632.  
  633. We support run-time schema evolution.  It uses a lazy scheme, so
  634. schema operations are very fast.  Objects on disk may have an older
  635. `storage class' and they will be updated to the new schema when they
  636. are used.
  637.  
  638. In older releases schema evolution was allowed only on leaf classes
  639. (those with no subclasses).  In our new release 2 (going to beta test
  640. soon) you can do schema evolution on any class.
  641.  
  642. In the future we're working on more general view mechanisms so you can
  643. see a subset of the attributes in memory, or some more complicated
  644. transformation.  This goes together with support for multiple
  645. compilers and multiple languages.
  646.  
  647. [Joe Keane <osc!jgk@amd.com>]
  648.  
  649.  
  650.  
  651.  
  652.                          <<< OTHER MODELS >>>
  653.  
  654.                         << Research Systems >>
  655.  
  656. >> IRIS (HP Labs)
  657.  
  658. Objects in the Iris system may acquire or lose types dynamically.
  659. Thus, if an object no longer matches a changed definition, the user
  660. can choose to remove the type from the object instead of modifying the
  661. object to match the type.  In general, Iris tends to restrict class
  662. modifications so that object modifications are not necessary.  For
  663. example, a class cannot be removed unless it has no instances and new
  664. supertype-subtype relationships cannot be established.
  665.  
  666. REFERENCES:
  667.         D.H. Fishman, D. Beech, H.P. Cate, E.C. Chow, T.
  668.         Connors, J.W. Davis, N. Derrett, C.G. Hock, W. Kent,
  669.         P. Lyngbaek, B. Mahbod, M.A. Neimat, T.A. Tyan, M.C.
  670.         Shan. "Iris: An Object-Oriented Database Management
  671.         System".  ACM Transactions on Office Information
  672.         Systems 5(1):48-69, Jan 1987.
  673.  
  674. [clamen]
  675.  
  676.  
  677.  
  678.                        << Commercial Systems >>
  679.  
  680.  
  681. >> IDL (Persistent Data Systems)
  682.  
  683. IDL is a schema definition language. Schema modifications are defined
  684. in IDL, requiring ad-hoc offline transformations of the database, in
  685. general.  A simple class of transformations can be handled by
  686. IDL->ASCII and ASCII->IDL translators (i.e., integer format changes,
  687. list->array, attribute addition).
  688.  
  689. [conversation with Ellen Borison of Persistent Data Systems]
  690.  
  691.  
  692. ADDITIONAL REFERENCES:
  693.         John R. Nestor. "IDL: The Language and Its
  694.         Implementation". Prentice Hall. Engelwood Cliffs,
  695.         NJ., 1989.
  696.  
  697.  
  698.  
  699. >> Kala
  700.  
  701. Kala manages an untyped persistent store, implementing the semantics
  702. of robust, distributed, secure, changing, and shareable persistent
  703. data.  Layers built upon the Kala platform can implement the semantics
  704. of objects with the same properties.
  705.  
  706. As it operates below the schema layer, Kala does not address schema
  707. evolution directly. However, It supports the building of schema'ed
  708. layers above it and below the application, and those layers can
  709. provide for schema evolution conveniently using Kala primitives.
  710. This parts-box approach requires extra work on the part of the developer
  711. compared to out-of-the-box solutions, but provides power and
  712. flexibility sufficient for relatively low cost solutions in
  713. difficult environments (e.g. graph-structured data, dynamic classing) 
  714. where no out-of-the-box solution is available.
  715.  
  716. [Ivan Godard <ivang@cup.portal.com>]
  717.  
  718.  
  719.  
  720. For more information, contact either Sergiu Simmel (sss@world.std.com)
  721. or Ivan Godard <ivang@cup.portal.com>.
  722.  
  723.  
  724. REFERENCES:
  725.         Segui S. Simmel and Ivan Godard. "The Kala Basket: A
  726.         Semantic Primitive Unifying Object Transactions,
  727.         Access Control, Versions, annd Configurations
  728.  
  729. [clamen]
  730.  
  731.  
  732.  
  733. >> Pick
  734.  
  735. With Pick and its variants you only have problems if you want to
  736. redefine an existing field.  Because of the way the data are stored
  737. and the separation of the data and the dictionary you can define
  738. additional fields in the dictionary without having to do anything to
  739. the data - a facility which we have found very useful in a number of
  740. systems.
  741.  
  742. There is no general facility to redefine an existing field - you just
  743. make whatever changes are required in the dictionary then write an
  744. Info Basic program to change the data.  We have seldom needed to do
  745. this, but it has not been complicated to do.
  746.  
  747. If a field in the database is no longer used, it is often easiest
  748. simply to delete the reference to that field in the dictionary, and
  749. accept the storage overhead of the unused data.  In such cases, while
  750. the data cannot be accessed through the query language, (Pick)Basic
  751. programs can still access them.
  752.  
  753. [Geoff Miller <ghm@ccadfa.cc.adfa.oz.au>]
  754.  
  755.  
  756. APPENDIX C  Object-Oriented Languages and Vendors
  757. =================================================
  758.  
  759. This APPENDIX is yet to be written.  Contributions are welcome.
  760.  
  761.  
  762. APPENDIX D  Object-Oriented CASE (OOA/D/P Tools) and Vendors
  763. ============================================================
  764.  
  765. The following tentative list comes from Ronald C. Schultz (of Berard Software
  766. Engineering), who posted this on 9/13/92.  Additional short entries are
  767. encouraged; please send additions to the author of the FAQ (and/or to Ron).
  768.  
  769. From: Ronald C. Schultz <ron@bse.com> <info@bse.com>
  770.  
  771. The following is a list of object-oriented CASE tools, as identified in
  772. advertisements in Object Magazine, Software Magazine, and 
  773. JOOP.  If you know of any additional vendors, please e-mail me.
  774. Also, if you know the costs for these tools, please let me know.
  775. I will repost with any updates.  
  776. Thanx.
  777. ------------------------------------------
  778. [format - Vendor name, city/state, phone (if known),
  779. tool name, operating systems, description and methods]
  780. -----------------------------------------
  781.  
  782. Andersen Consulting
  783. Chicago, Il.
  784. Foundation
  785. MVS, PC-DOS, OS/2, VAX/VMS, GCOS
  786. Object-oriented full life-cycle tools
  787.  
  788. Bachman Information Systems
  789. Burlington, Ma.
  790. 800-222-4626
  791. Bachman Data Analyst
  792. PC-DOS, OS/2
  793. Data Modeling and analysis with OO support
  794.  
  795. Cadre Technologies
  796. Providence, R.I.
  797. 401-351-CASE
  798. Teamwork
  799. VAX/VMS, Unix, OS/2, PC-DOS
  800. CASE toolset with object-oriented capabilities
  801. Shlaer/Mellor, HOOD
  802.  
  803. Chen & Associates, Inc.
  804. Baton Rouge, La.
  805. 514-928-5765
  806. OBJECT-DESIGNER
  807. ?? platforms supported unknown ??
  808. Graphical object-oriented design tool
  809.  
  810. Excel Software
  811. Marshalltown, Ia.
  812. 515-752-5359
  813. MacAnalyst and MacDesigner
  814. Macintosh
  815. Object-oriented analysis
  816.  
  817. GE Advanced Concepts Center
  818. King of Prussia, Pa.
  819. 215-992-6200 or
  820. 800-438-7246
  821. OMTool
  822. ?? platforms supported unknown ??
  823. Object-oriented analysis and design
  824. Rumbaugh
  825.  
  826. Hamilton Technologies
  827. Cambridge, Ma.
  828.  
  829. 001
  830. VAX/VMS, Unix
  831. Object-oriented, full life cycle CASE
  832.  
  833. Hewlett Packard
  834. Cupertino, Ca.
  835. 800-752-0900 ext. 2707
  836. or 303-229-2255
  837. HP C++/Softbench
  838. HP, Apollo
  839. CASE tool integration, C/C++ development
  840.  
  841. Iconix Software Engineering
  842. Santa Monica, Ca.
  843. Iconix Power Tools
  844. Macintosh
  845. Multiuser, OO development toolset
  846.  
  847. Interactive Development Environments
  848. San Francisco, Ca.
  849. Software Through Pictures
  850. VAX/VMS, Unix
  851. Object-oriented structured design with multi-user OO data dictionary
  852. Wasserman's OOSD
  853.  
  854. Knowledge Garden, Inc.
  855. Nassau, N.Y.
  856. KnowledgePro /
  857. Windows
  858. Windows
  859. OO Development environment with C++ code generation
  860.  
  861. Mark V Software
  862. Encino, Ca.
  863. 818-995-7671
  864. ObjectMaker
  865. Windows, Unix, Macinstosh
  866. Object-oriented analysis and design
  867. Berard, Booch, Coad/Yourdon, Colbert, Rumbaugh, and others
  868.  
  869. Object International, Inc.
  870. Austin, Tx.
  871. 512-795-0202 or
  872. 800-926-9306
  873. OOATool
  874. Unix, Macintosh, Windows
  875. Object-oriented analysis
  876. Coad/Yourdon
  877.  
  878. Palladio Software, Inc.
  879. Brookfield, Wi.
  880. 1-800-437-0019 or
  881. 414-789-5253
  882. Object System/Designer
  883. Windows
  884. Object-oriented design
  885. Booch
  886.  
  887. Popkin Software
  888. N.Y., N.Y.
  889. 212-571-3434
  890. System Architect
  891. Windows, OS/2
  892. Object-oriented design
  893.  
  894. Protosoft
  895. Houston, Tx.
  896. 713-480-3233
  897. Paradigm Plus
  898. Windows, Unix, OS/2
  899. CASE toolset supporting  Berard (EVB), Booch, Coad/Yourdon, and others
  900.  
  901. Rational
  902. Santa Clara, Ca.
  903. 408-496-3700
  904. Rose
  905. Unix, AIX
  906. Object-oriented analysis and design
  907. Booch
  908.  
  909. Semaphore
  910. North Andover, Ma.
  911. 508-794-3366 or
  912. 800-937-8080
  913. ATRIOM
  914. ?? platforms supported unknown ??
  915. Object-oriented analysis and design
  916.  
  917. StructSoft
  918. Bellevue, Wa.
  919. 206-644-9834
  920. TurboCase
  921. Macintosh
  922. Object-oriented analysis, structured design
  923.  
  924. Texas Instruments, Inc.
  925. 800-527-3500
  926. IEF
  927. ?? platforms supported unknown ??
  928. Object-oriented information engineering
  929.  
  930. TGS Systems
  931. Halifax, Nova Scotia
  932. 902-455-4446
  933. Prograph
  934. Macintosh
  935. OO visual programming environment
  936.  
  937. Roman Zielinski Metod & SystemUtveckling
  938. Norsborg, Sweden
  939. OOTher 
  940. Windows
  941. OO Documentation Tool
  942. Coad/Yourdon
  943.  
  944.  
  945.  
  946. APPENDIX E  Anonymous FTP Sites
  947. ===============================
  948.  
  949. These are anonymous ftp sites of interest to the OO community.  Thanks go to
  950. Mike DeVaney (dm_devaney@pnl.gov gen ftp site list) and to Bill Kinnersley
  951. (anon ftp programming languages list), whose initial lists helped to get
  952. things going.  Additional short entries are encouraged; please send additions
  953. to the author of the FAQ (and/or to Mike and Bill).
  954.  
  955. Entries will be standardized and summarized in future (non-draft) FAQs
  956. and are not limited to one category.
  957.  
  958. Starred entries have a summary.
  959.  
  960. PROGRAMMING LANGUAGES
  961. =====================
  962.  
  963. ftp.inria.fr                       *ALCOOL-90 (dyn ML)
  964. monch.edrc.cmu.edu:/usr0/snl/archive/bos-1.2   *BOS (prototyping)
  965. grape.ecs.clarkson.edu:/pub/msdos/djgpp/djgpp.zip C++ (for MS-DOS)
  966. prep.ai.mit.edu:/pub/gnu/g++-1.39.0.tar.Z     C++ (for Unix)
  967. parcftp.xerox.com:pcl                 CLOS
  968. pion.lcs.mit.edu                CLU (Sun, VAX)
  969. ftp.cs.cornell.edu:/pub/CML-0.9.tar.Z        CML
  970. arisia.xerox.com                Pcl (Portable CommonLoops)
  971. xcf.berkeley.edu:src/local/fmpl               *FMPL (prototyping)
  972. nebula.cs.yale.edu                Glasgow Haskell
  973. piggy.cs.chalmers.se                Chalmers Haskell (hbc)
  974. software.watson.ibm.com                Hermes (Unix)
  975. cs.arizona.edu                    Icon
  976. sun.soe.clarkson.edu                ISETL (DOS, Mac, Unix, VMS,src)
  977. cs.orst.edu                    Little Smalltalk (C src)
  978. gatekeeper.dec.com                Modula-3
  979. obj3dist@csl.sri.com (licence or request)      *OBJ3 (OO lang)
  980. gate.fzi.de                       *OBST (lang, perst)
  981. neptune.inf.ethz.ch                Oberon (MacII, SPARC, DECstn)
  982. wuarchive.wustl.edu:/mirrors/msdos/pgmutl/oberon11.zip Oberon (MS-DOS)
  983. ux1.cso.uiuc.edu:pub/amiga/fish/ff380        Oberon (Amiga)
  984. watserv1.waterloo.edu                occam (VAX sim, Tahoe)
  985. wuarchive.wustl.edu:/mirrors/unix-c/languages/ops5 OPS5 (interpreter)
  986. wuarchive.wustl.edu:/mirrors/msdos/pli/runpli1a.arc PL/I (interpreter)
  987. watserv1.waterloo.edu                Russell
  988. icsi-ftp.berkeley.edu                   *Sather (simple Eiffel)
  989. altdorf.ai.mit.edu: scm                Scheme (small, portable)
  990. gatekeeper.dec.com: elk             Scheme (for Suns)
  991. acorn.cs.brandeis.edu: gambit             Scheme (for 68K's)
  992. otis.stanford.edu                   *Self
  993. self.stanford.edu                Self
  994. cs.nyu.edu                    SETL2 (DOS, OS/2, Mac, Unix)
  995. rascal.ics.utexas.edu                SIMULA 67 (Mac)
  996. prep.ai.mit.edu:pub/gnu                Smalltalk-80 (GNU v1.1)
  997. st.cs.uiuc.edu                    Smalltalk V
  998. cs.yale.edu:pub/ml                SML/NJ
  999. research.att.com:dist/ml            SML (Version 0.75)
  1000. sbcs.sunysb.edu                    SML (lazy)
  1001. gatekeeper.dec.com                Modula-3 (SRC)
  1002. ucbvax.berkeley.edu                tcl
  1003. ftp.cs.umu.se:/pub/umlexe01.zoo            uML
  1004.  
  1005. COMPILER TOOLS
  1006. ==============
  1007. prep.ai.mit.edu:pub/gnu/bison-1.14.tar.Z    Yacc
  1008. ftp.th-darmstadt.de:/pub/programming/languages/C++ *(C++ gram, etc.)
  1009.  
  1010. DATABASES
  1011. =========
  1012. ftp.cs.wisc.edu:exodus                *Exodus    (Storage Man, perst)
  1013. gate.fzi.de:/pub/obst                *OBST    (schema, perst objs)
  1014. postgress.berkeley.edu:pub            *POSTGRESS (Ext. Rel. DBMS)
  1015. mood.mech.tohoku.ac.jp                *MOOD      (OODB, lim arch.)
  1016. email: nhg@research.att.com            *ODE    (C++ OODB)
  1017.  
  1018. TOOLS AND CASE
  1019. ==============
  1020. ftp.th-darmstadt.de:/pub/programming/languages/C++ *(Cls bwsr, tmplates, GC et)
  1021. iamsun.unibe.ch                    *Sniff (C++ devel environ)
  1022. ftp.centerline.com:/pub/tags-1.0.tar.Z        *C++ tags
  1023.  
  1024. LIBRARIES AND INTERFACES
  1025. ========================
  1026. ftp.th-darmstadt.de:/pub/programming/languages/C++ *(NIHCL COOL OATH ET++ etc.)
  1027. csc.ti.com:pub/COOL.tar.Z            *COOL(C++, orig from TI)
  1028. cs.utexas.edu:pub/COOL/GE_COOL2.1.tar.Z        *COOL(C++, Cfront 2.1, from GE)
  1029. omg.org:pub/corba.ps.Z{/NEC_DII/93-1-2...}    *CORBA (DII)
  1030.  
  1031. DOCUMENTATION
  1032. =============
  1033. ftp.th-darmstadt.de:/pub/programming/languages/C++ *(C++ docs, code, net sum's)
  1034.  
  1035. GENERAL
  1036. =======
  1037. ftp.th-darmstadt.de:/pub/programming/languages/C++ *(lots for C++)
  1038. st.cs.uiuc.edu                    *Manchester Archive and some
  1039.  
  1040.  
  1041.  
  1042. What: Interpreter for FMPL of Accardi, Release 1
  1043. From: blojo@xcf.berkeley.edu (Jon Blow)
  1044. Date: 2 Jun 92 08:42:26 GMT
  1045.  
  1046. An interpreter for FMPL of Accardi, Release 1 is now available for ftp at 
  1047. xcf.berkeley.edu:src/local/fmpl/.
  1048.  
  1049. *FMPL is a prototype-based object-oriented programming language.
  1050. *FMPL possesses lambda-calculus based constructs.
  1051. *FMPL is an event-driven language; the events it responds to are mainly
  1052. based on the behavior of input/output streams, not only within the unix domain
  1053. but across the internet as well.
  1054. *FMPL supports "pretty"-printing of internally-represented code back into
  1055. readable form.
  1056. *FMPL is an experimental language developed at the Experimental Computing 
  1057. Facility of the University of California, Berkeley.  This release is something
  1058. of a beta test since the language has not been widely used outside Berkeley.
  1059. It is hoped that this release will draw useful comments and suggestions from
  1060. the world at large that will help in improving future versions of FMPL.
  1061.  
  1062. What: MOOD/P3 Ver.2.00 OODBS {Miniature,Materials}OODBS.
  1063. From: ono@mood.mech.tohoku.ac.jp (Noboru Ono)
  1064. Date: 18 May 92 10:28:42 GMT
  1065.  
  1066. The following program/sample database package is available through anonymous
  1067. FTP at mood.mech.tohoku.ac.jp (130.34.88.61). Sorry it is not the sources and
  1068. operates only in NEC-PC9801/MS-DOS environment.  Sorry again documents are all
  1069. in Japanese. We will tell you later when English documents has become ready.
  1070.  
  1071.       MOOD/P3 Ver.2.00
  1072.       Material's Object-Oriented Database, Prototype 3
  1073.  
  1074. This program, as you may guess,
  1075.  
  1076.       1) is an Object-Oriented database system program,
  1077.       2) operates on PC-9801 series personal computer, and
  1078.       3) is accompanied by sample material database schema.
  1079.  
  1080. Although this program has been developed and being used in the experiments
  1081. on material data processing in which we are now involved, it is a general
  1082. purpose OODBS. 
  1083.  
  1084. What: ftp site for C++ material
  1085. From: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
  1086. Date: 27 May 92 22:32:35 GMT
  1087.  
  1088. There were a lot of questions about C++ material in the last time and some 
  1089. announcements which involved our ftp server.
  1090.         ftp.th-darmstadt.de [130.83.55.75]
  1091.         /pub/programming/languages/C++
  1092. At the moment we have:
  1093.  -- documentation and assorted stuff
  1094.         C++ products list as announced by Saumen K Dutta (in a subdirectory!)
  1095.         C++ YACC grammar, ET++ tutorial, summaries from the Net,
  1096.         sources from James Coplien's book (idioms...), etc.
  1097.  -- class libraries
  1098.         NIHCL (original, persistent for ObjectStore, with g++ 1.4x changes)
  1099.         COOL, OATH, RogueWave vector, ET++,
  1100.         RPC package, a package for sockets, awe (thread package)
  1101.  -- tools
  1102.         class browser (for GNU Emacs), indent++, yacc+, template
  1103.         processor of Brad Cox[sp?], DEC garbage collector
  1104.  
  1105. More stuff is always welcome.  (Btw, Interviews and Motif C++ wrapper
  1106. classes are to be found in the /pub/X11 subtree.)
  1107.  
  1108. What: Alcool-90 Release 0.40.3
  1109. From: rouaix@inria.fr (Francois Rouaix)
  1110. Date: 18 May 92 09:36:22 GMT
  1111.  
  1112. Alcool-90 is an experimental extension of ML with run-time overloading and
  1113. a type-based notion of modules, functors and inheritance.
  1114.  
  1115. New constructs have been added:
  1116.         * Overloaded symbols (overload).
  1117.         * Local definition of abstract values (overload in).
  1118.         * Implementations and parametric functors (pack to). 
  1119.         * Extension functors (overload with).
  1120.         * Class-based Dynamics (dynamic).
  1121.  
  1122. This version of Alcool is based on the CAML Light implementation (release
  1123. 0.4) of the ML language, but this release is autonomous.
  1124.  
  1125. Alcool-90 is available by anonymous FTP from ftp.inria.fr:
  1126.  
  1127.     host:      ftp.inria.fr  (128.93.1.26)
  1128.     directory: lang/alcool
  1129.     files:
  1130.      README                 Copyright information.
  1131.      alcool270492.tar.Z     Sources for Un*x machines (Apr 27 1992 Release).
  1132.      alcooldoc.dvi.tar.Z    DVI for the Alcool-90 report draft.
  1133.  
  1134. For questions, comments, bug reports, please e-mail to Francois.Rouaix@inria.fr
  1135.  
  1136. What: Ode Release 1.1
  1137. From: nhg@research.att.com
  1138.  
  1139. Ode is an object-oriented database based on the C++ database model. The
  1140. primary interface to Ode is the database programming language O++ which is
  1141. based on C++.
  1142.  
  1143. Ode 1.1 is now available to Universities.  This is a beta release.  The
  1144. current version of Ode runs on Sun (Sparc) workstations and users must have
  1145. C++ release 2.0 or a later release.  If you are interested in using Ode and
  1146. giving us feedback on your experience with Ode, please send me mail with the
  1147. appropriate information.
  1148.  
  1149. Narain Gehani
  1150. AT&T Bell Labs 3D-414
  1151. 600 Mountain Ave
  1152. Murray Hill, NJ 07974
  1153.  
  1154.  
  1155. What: SmallTalk
  1156. From: johnson@m.cs.uiuc.edu (Ralph Johnson)
  1157. Date: 18 Dec 91 19:41:38 GMT
  1158.  
  1159. We have a complete copy of everything in the Manchester archive, and you
  1160. can either access it by e-mail like the Manchester archive or by anonymous
  1161. ftp.  Our archive is on st.cs.uiuc.edu, and you can get information about the
  1162. e-mail server by sending to archive-server@st.cs.uiuc.edu, and putting the
  1163. line help in your message. We actually have a little more than is in the
  1164. Manchester archive.  We have the Smalltalk-V code from the defunct
  1165. International Smalltalk Association, and a few other odds and ends.
  1166.  
  1167. What: OBST (Version: OBST3-2)
  1168. From: stone@fzi.de
  1169. Date: 19/3/92
  1170.  
  1171. [ Formerly, we used the acronym SOS, which led to a conflict
  1172.   with an object oriented operating system of the same name.
  1173.   Therefore we changed the name to OBST ("Obst" is the German 
  1174.   word for "fruit"). As many people already use SOS (OBST) we 
  1175.   did not change internal things like class names, environment 
  1176.   variables and so on. ]
  1177.  
  1178. The persistent object management system OBST was developed by
  1179. Forschungszentrum Informatik (FZI) as a contribution to the STONE
  1180. project. This project (supported by grant no. ITS8902A7 from the
  1181. BMFT, i.e. the German Ministry for Research) aims at the development
  1182. of a software engineering environment for education purposes and is
  1183. carried out as a joint project of nine german universities and
  1184. research institutions.
  1185.  
  1186. An essential feature of STONE is that the object oriented paradigm 
  1187. is pursued consequently as a key concept. OBST is the common persistent
  1188. object store for all tools within the STONE environment. 
  1189.  
  1190. The OBST data model can be characterized by the following properties:
  1191.  
  1192.  * Schema definition language syntactically similar to C++
  1193.  * Support of multiple inheritance
  1194.  * Generic classes
  1195.  * Distinction between public, protected, and private methods
  1196.  * Redefinition of methods
  1197.  * Overloading of methods
  1198.  
  1199. Schemas are compiled by the OBST schema compiler. The compilation
  1200. results are instances of classes of the meta schema. From these
  1201. instances in a next step interfaces to different programming languages
  1202. can be generated. At present the C++ language binding is implemented,
  1203. interfaces to Lisp and other languages are planned.
  1204.  
  1205. Objects are stored in so-called containers. The container an object
  1206. belongs to is determined at the time of object creation and fixed
  1207. throughout the object's lifetime. Containers are the units of 
  1208. clustering, synchronization, and recovery. Objects can be referenced
  1209. by other objects across container boundaries.
  1210.  
  1211. OBST provides a mechanism to incrementally load methods. This enables
  1212. programs to deal with objects whose type is defined after the program 
  1213. itself has been developed. This is useful in systems that provide for 
  1214. inheritance and it supports schema evolution.
  1215.  
  1216. Since end 1990 the first prototype of OBST is available and is shipped
  1217. to interested universities and research institutions. 
  1218.  
  1219. The system comes with the schema compiler, a library of predefined
  1220. classes, a graphical object browser, the structurer and flattener and the
  1221. OShell, and all 
  1222. manuals. 
  1223.  
  1224. Structurer and Flattener is a tool to build objects from bytestrings and
  1225. flatten objects down to bytestrings. It is intended to be used when coupling
  1226. UNIX tools to the object management system. The user defines a grammar
  1227. that describes her objects. Afterwards, the structurer parses an ascii 
  1228. text according to the given grammar and creates an OBST object structure that
  1229. represents the corresponding parse tree.  The flattener does the inverse
  1230. transformation, that means it generates an ascii text from a given OBST object
  1231. structure according to the given grammar.
  1232.  
  1233. OShell is a tool which provides interactive access to the OBST object base.
  1234. There is a language called OSL which is based on the lambda calculus and
  1235. defines the interface to the OShell tool.
  1236.  
  1237. For the prototype's installation a C++ compiler (GNU g++ 1.37 or later or AT&T
  1238. 2.0/2.1) and the X-Windows system (currently X11R4) for the graphical tools
  1239. are required. Installation is well-tried on SUN 3/* and SUN 4/* systems and
  1240. should be no problem on other UNIX machines, too.
  1241.  
  1242. --------------------------------------------------------------------
  1243. For more information please mail to:
  1244.                 Forschungszentrum Informatik (FZI)
  1245.                        STONE Projekt
  1246.                  Haid-und-Neu-Strasse 10-14
  1247.                      D-7500 Karlsruhe 1
  1248.                           Germany
  1249. or email to:  stone@fzi.de
  1250.  
  1251. Phone:        ++49-721-9654-601
  1252. Fax:          ++49-721-9654-609
  1253. Teletex:      721 190 fziKA
  1254.  
  1255. The OBST system is available via anonymous FTP from gate.fzi.de
  1256. [141.21.4.3]. The system can be found in the directory /pub/OBST.
  1257.  
  1258. Sites interested in getting information about new OBST developments
  1259. are welcome to register in our mailing list by sending an email with
  1260. subject "obst-mailing-list" to stone@fzi.de.
  1261.  
  1262. What: BOS
  1263. From: Sean.Levy@cs.cmu.edu
  1264. Date: 23 Apr 92 18:07:32 GMT
  1265.  
  1266. [For readers of comp.object and self-interest, BOS is a prototype-based
  1267. object system that I have, er, prototyped in Tcl. It is available via anon
  1268. FTP to monch.edrc.cmu.edu under /usr0/snl/archive/bos-1.2.tar.Z (you have to
  1269. cd to /usr0/snl/archive first and then get the file, due to CMU security hacks
  1270. in ftpd). I thought that this would be of interest to comp.object and
  1271. self-interest, so I'm cross-posting/mailing --S]
  1272.  
  1273. Note: I play very fast and loose with the terminology of OOP to get my
  1274. point across. I appoogize if I offend any sensibilities, and will clarify what
  1275. I say if it is obfuscated by my use of terms.
  1276.  
  1277.  
  1278. What: SATHER
  1279.  
  1280. Sather is under development at the International Computer Science Institute.
  1281. Sather has clean and simple syntax, parameterized classes, object-oriented
  1282. dispatch, multiple inheritance, strong typing, and garbage collection. The
  1283. compiler generates efficient and portable C code which is easily integrated
  1284. with existing code.
  1285.  
  1286. The initial beta test release of the language was in May, 1991. The compiler,
  1287. debugger, Emacs development environment, documentation, and library classes
  1288. are available by anonymous ftp from "icsi-ftp.berkeley.edu".
  1289. "sather@icsi.berkeley.edu" is a mailing list for discussing aspects of Sather
  1290. and "sather-admin@icsi.berkeley.edu" should be used for bug reports and
  1291. requests to be added or deleted from the mailing list.
  1292.  
  1293. Sather is based on Eiffel but is more concerned with efficiency and less with
  1294. some of the formal and theoretical issues addressed by Eiffel. The language is
  1295. much smaller than the current Eiffel, it eliminates over 40 keywords and
  1296. simplifies the syntax and inheritance rules. 
  1297.  
  1298. Like Eiffel, Sather code is compiled into portable C and efficiently links
  1299. with existing C code. The Sather compiler is written in Sather and has been
  1300. operational for almost a year, though it is still being improved. Preliminary
  1301. benchmarks show a performance improvement over Eiffel of between a factor of 4
  1302. and 50 on basic dispatching and function calls. On the benchmarks used at
  1303. Stanford to test Self (including 8 queens, towers of hanoi, bubblesort, etc),
  1304. Sather is even slightly faster than C++.
  1305.  
  1306. The Sather compiler and libraries are publicly available under a very
  1307. unrestrictive license aimed at encouraging contribution to the public library
  1308. without precluding the use of Sather for proprietary projects.  The goal is to
  1309. establish a repository for efficient, reusable, well written, publicly
  1310. available, classes for most of the important algorithms in computer science.
  1311. There are currently about 120 classes in the library. The libraries are
  1312. growing quickly and will collect together classes from many authors under the
  1313. same unrestrictive license. 
  1314.  
  1315. A GNU emacs development environment for Sather is available. A debugger based
  1316. on gdb from the Free Software Foundation is also available. A parallel version
  1317. of Sather for shared memory machines called "Psather" is also under
  1318. development.
  1319.  
  1320. What: C++ products list
  1321. From: Sean.Levy@cs.cmu.edu
  1322. Host:   ftp.th-darmstadt.de
  1323. Dir:      /pub/programming/languages/C++/c++-products
  1324.  
  1325. It's there in ASCII, texinfo, troff, DVI, and PostScript version.
  1326.  
  1327. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  1328. Joachim Schrod                  Email: schrod@iti.informatik.th-darmstadt.de
  1329. Computer Science Department
  1330. Technical University of Darmstadt, Germany
  1331.  
  1332.  
  1333.  
  1334. What: SNIFF (Sniff 1.1b (C++ Development Environment))
  1335. From: shite@sinkhole.unf.edu (Stephen Hite)
  1336. Date: 23 Aug 92 18:14:00 GMT
  1337.  
  1338. Sniff 1.1b is available from iamsun.unibe.ch in the C++ hierarchy.  It's a
  1339. development environment for C++ (minus the C++ compiler or interpreter).
  1340. It's freely available and you're gonna need OpenWindows 3.0 if you want
  1341. to play with it immediately.  I just downloaded it and haven't had a 
  1342. chance to look into whether the XView 3.0 package will be able to handle
  1343. everything Sniff requires of the OpenLook part.
  1344.  
  1345. What: COOL
  1346.  
  1347. COOL is a C++ class library developed at Texas Instruments.
  1348.  
  1349. Features are:
  1350. 1. Rich set of containers like Vector, List, Hash_Table, Matrix, etc...
  1351. 2. Hierarchy is shallow with no common base class, rather than deep like NIHCL.
  1352. 3. Functionality close to Common Lisp data structures, like GNU libg++.
  1353. 4. Template syntax very close to Cfront3.x, g++2.x.
  1354. 5. Free, with good documentation, and extensive test cases.
  1355.  
  1356. Light version of COOL from General Electric:
  1357. 1. Hairy macros, run-time type, exceptions removed for mainstream C++
  1358.    compatibility
  1359. 2. Free of memory leaks and bound violations. Leaks and bounds are checked
  1360.    with Purify.
  1361. 3. Has memory management and efficient copy in expressions like:
  1362.   Set c = a+b+c;    
  1363.   Pointers are shared with Handle and Reference count. Deep copy in
  1364.   expressions are replaced by shallow copy.
  1365. 4. Compatible with Cfront2.1, and is being converted to Cfront3.0. You can
  1366.   build both static and shared library on SunOS 4.1.x
  1367.  
  1368. 1. original version from Texas Instruments:
  1369.    at csc.ti.com, get pub/COOL.tar.Z
  1370. 2. Cfront2.1 version modified by General Electric:
  1371.    at cs.utexas.edu, get pub/COOL/GE_COOL2.1.tar.Z
  1372.  
  1373. I am working on Cfront3.0 version of COOL, using the Beta 3.0 from Sun. I am
  1374. experiencing problems with instantiation and specialization of templates.  So
  1375. Cfront3.0 version of COOL won't be available until Sun's Cfront 3.0 is
  1376. released with bugs fixed.
  1377.  
  1378. Van-Duc Nguyen
  1379. General Electric 
  1380. Research & Development Ctr
  1381. 1 River Road, Room K1-5C39.
  1382. Schenectady, NY 12301.
  1383. Phone: (518) 387-5659
  1384. Fax:   (518) 387-6845
  1385. nguyen@crd.ge.com
  1386.  
  1387.  
  1388. What: ctags/etags for C and C++
  1389. From: kendall@centerline.com (Sam Kendall)
  1390. Date: 10 Jun 92 09:31:27 GMT
  1391.  
  1392. A lot of people have requested this software!  You can now get Tags for
  1393. C/C++ version 1.0 via anonymous ftp at:
  1394.  
  1395.         ftp.centerline.com:/pub/tags-1.0.tar.Z
  1396.  
  1397. ftp.centerline.com is 140.239.2.29.  Anonymous ftp means login as "ftp" and
  1398. give your email address as the password.
  1399.  
  1400. If you don't have ftp access to the internet, you may want to wait for this
  1401. stuff to come out in comp.sources.unix.  Or, if you plan to use it right away,
  1402. send me a letter that says "I can't use ftp; please send by email" and I will
  1403. do so.
  1404.  
  1405.  
  1406. What: Version 4.0 of the POSTGRES DBMS
  1407. From: mer@gaia.CS.Berkeley.EDU (Jeff Meredith)
  1408. Date: 16 Jul 92 04:53:17 GMT
  1409.  
  1410. Version 4.0 of the POSTGRES DBMS is now available for distribution. Version 4.0 
  1411. provides significant advances in functionality over 3.1.  General improvements
  1412. in the code and some key multi-user bug fixes have resulted in a much more
  1413. reliable system than we have ever previously released.
  1414.  
  1415. Major new features include:
  1416.  o  Complete support for language (POSTQUEL) functions.
  1417.  o  Handling of nested dot expressions.
  1418.  o  Optimization of predicates with expensive functions.
  1419.  o  Binary portals
  1420.  o  Initial support of sets
  1421.  o  Indices on system catalogs.
  1422.  
  1423. Postgres runs on Sparc I, Sparc II, Sun 4 running SunOs, and DECstations
  1424. running ULTRIX >= 4.0, as well as Sequent Symmetry machines.  Postgres
  1425. consists of about 250,000 lines of C.
  1426.  
  1427. If you would like to get Postgres 4.0, you can get it in one of two ways:
  1428.  
  1429. (1)  Anonymous FTP from postgres.berkeley.edu
  1430.  
  1431. cd pub
  1432. get postgres-setup.me
  1433. binary
  1434. get postgres-v4r0.tar.Z
  1435. quit 
  1436.  
  1437. Or, if you do not have net.access, you can order a Postgres distribution
  1438. tape by sending a check payable to the Regents of the University of California
  1439. for $150.00 to:
  1440.          Postgres Project
  1441.          571 Evans Hall
  1442.          University of California
  1443.          Berkeley, CA 94720.
  1444.  
  1445. Indicate in your accompanying letter whether you want the system on a 9-track
  1446. tape at 1600 BPI, at 6250 BPI, on a cartridge tape for SUN shoeboxes (QIC 24 
  1447. format), or on a TK50 DEC cartridge tape.
  1448.  
  1449.  
  1450. What: SELF optimizing compiler and Thesis
  1451. From: chambers@cs.washington.edu (Craig Chambers)
  1452. Date: 9 May 92 22:00:53 GMT
  1453.  
  1454. My Ph.D. thesis, entitled "The Design and Implementation of the Self Compiler,
  1455. an Optimizing Compiler for Object-Oriented Programming Languages," is now
  1456. available as Stanford technical report number STAN-CS-92-1420.  Copies may be
  1457. ordered from Stanford.  Stanford requires $20 (plus tax for orders from within
  1458. California), in advance, for each copy.
  1459.  
  1460. The dissertation also is available in compressed postscript form.  The
  1461. electronic version may be copied via anonymous ftp from self.stanford.edu in
  1462. the directory pub/papers/chambers-thesis.  This version is free.  Note however
  1463. that the thesis is about 250 pages long.
  1464.  
  1465.  
  1466. What: Self 2.0 Release
  1467. From: hoelzle@Xenon.Stanford.EDU (Urs Hoelzle)
  1468. Date: 10 Aug 92 21:08:25 GMT
  1469.  
  1470. Announcing Self Release 2.0
  1471.  
  1472. The Self Group at Sun Microsystems Laboratories, Inc., and Stanford University
  1473. is pleased to announce Release 2.0 of the experimental object-oriented
  1474. exploratory programming language Self.
  1475.  
  1476. Release 2.0 introduces full source-level debugging of optimized code, adaptive 
  1477. optimization to shorten compile pauses, lightweight threads within Self,
  1478. support for dynamically linking foreign functions, changing programs within
  1479. Self, and the ability to run the experimental Self graphical browser under
  1480. OpenWindows.
  1481.  
  1482. Designed for expressive power and malleability, Self combines a pure,
  1483. prototype-based object model with uniform access to state and behavior. Unlike
  1484. other languages, Self allows objects to inherit state and to change their
  1485. patterns of inheritance dynamically. Self's customizing compiler can generate
  1486. very efficient code compared to other dynamically-typed object-oriented
  1487. languages.
  1488.  
  1489. Self Release 2.0 runs on Sun-3's and Sun-4's, but no longer has an optimizing
  1490. compiler for the Sun-3 (and therefore runs slower on the Sun-3 than previous
  1491. releases).
  1492.  
  1493. This release is available free of charge and can be obtained via anonymous ftp
  1494. from self.stanford.edu. Unlike previous releases, Release 2.0 includes all
  1495. source code and is legally unencumbered (see the LICENSE file for legal
  1496. information.)  Also available for ftp are a number of papers published about
  1497. Self.
  1498.  
  1499. Finally, there is a mail group for those interested in random ramblings about
  1500. Self, self-interest@self.stanford.edu. Send mail to
  1501. self-request@self.stanford.edu to be added to it (please do not send such
  1502. requests to the mailing list itself!).
  1503.  
  1504. The Self Group  at Sun Microsystems Laboratories, Inc. and Stanford University
  1505.  
  1506.  
  1507. What: The Smalltalk Report
  1508. From: cdibble@bonnie.ics.uci.edu (Clifford Thomas Dibble)
  1509. Date: 11 May 92 19:48:25 GMT
  1510.  
  1511. I've received several requests for information about "The Smalltalk Report", so
  1512. here it is. For the record, I have no affiliation whatsoever with the
  1513. publisher.
  1514.  
  1515.                              The Smalltalk Report
  1516.                 The International Newsletter for Smalltalk Programmers
  1517.  
  1518. is published 9 times a year by
  1519. SIGS Publications Inc.
  1520. 588 Broadway, New York, NY.
  1521. 10012
  1522. (212) 274-0640
  1523.  
  1524. 1 year domestic subscription: $65
  1525. 1 year foreign/Canada       : $90
  1526. single copy price           : $8
  1527.  
  1528. Send subscription orders to
  1529.  
  1530. The Smalltalk Report
  1531. Subscriber Services
  1532. Dept. SML
  1533. P.O. Box 3000
  1534. Denville, NJ
  1535. 07834
  1536.  
  1537.  
  1538. What: Exodus project software (Storage Manager & GNU E)
  1539. From: zwilling@caseus.cs.wisc.edu (Mike Zwilling)
  1540. Date: 16 Jul 92 04:53:19 GMT
  1541.  
  1542. In the past there have been discussions in comp.object and comp.databases
  1543. about persistent storage for object-oriented databases and programming
  1544. languages.  As you may know, the EXODUS Database Toolkit project at the
  1545. University of Wisconsin has researched these issues and others for a number of
  1546. years.  The purpose of this note is to inform you that the software from the
  1547. EXODUS project is freely available via anonymous ftp.  The EXODUS software
  1548. includes the EXODUS Storage Manager and the compiler for the E persistent
  1549. programming language.  Also included is documentation, and a suite of test
  1550. programs for both components.  This note briefly describes the software and
  1551. explains how to obtain it.  We currently support DECstation 3100s/5000s and
  1552. SPARC based workstations.  Others have ported the code to HP700s and IBM
  1553. RS6000s.
  1554.  
  1555. The EXODUS Storage Manager is a client-server object storage system which
  1556. provides "storage objects" for storing data, versions of objects, "files"
  1557. for grouping related storage objects, and indexes for supporting efficient
  1558. object access.  A storage object is an uninterpreted container of bytes which
  1559. can range in size from a few bytes to hundreds of megabytes.  The Storage
  1560. Manager provides routines to read, overwrite, and efficiently grow and shrink
  1561. objects.  In addition, the Storage Manager provides transactions, lock-based
  1562. concurrency control, and log-based recovery.
  1563.  
  1564. GNU E is a persistent, object-oriented programming language developed as part
  1565. of the Exodus project.  GNU E extends C++ with the notion of persistent data,
  1566. program level data objects that can be transparently used across multiple
  1567. executions of a program, or multiple programs, without explicit input and
  1568. output operations.
  1569.  
  1570. GNU E's form of persistence is based on extensions to the C++ type system to 
  1571. distinguish potentially persistent data objects from objects that are always
  1572. memory resident.  An object is made persistent either by its declaration (via
  1573. a new "persistent" storage class qualifier) or by its method of allocation
  1574. (via persistent dynamic allocation using a special overloading of the new
  1575. operator).  The underlying object storage system is the Exodus storage manager,
  1576. which provides concurrency control and recovery in addition to storage for
  1577. persistent data.
  1578.  
  1579. The current release of GNU E is based on gcc/g++ version 2.2.2, and is upward 
  1580. compatible with C++ as implemented by that compiler.
  1581.  
  1582. A bibliography of EXODUS related papers can be obtained from the ftp site
  1583. described below.
  1584.  
  1585. To obtain the software, simply ftp to ftp.cs.wisc.edu (128.105.8.18), login
  1586. as anonymous with your email address as a password, "cd" to the "exodus"
  1587. directory, and follow the directions (directions will be given as you "cd").
  1588. See the README for the latest information about the software and an indication
  1589. of our future plans.  If you decide to use the software, please contact us at
  1590. exodus@cs.wisc.edu so that we can notify you of changes.
  1591.  
  1592.  
  1593. What: Release 2.0 of OBJ3 (needed for FOOPS and OOZE, concurrent OOP)
  1594. Date: Thu, 4 Jun 92 15:07:26 BST
  1595. From: Paulo.Borba@prg.oxford.ac.uk
  1596.  
  1597. OBJ is available from SRI, see the message below; prototypes implementations of
  1598. FOOPS (without the concurrent extension) and OOZE are due to the end of the
  1599. year, but for both you also need OBJ. 
  1600.  
  1601. Unfortunately, I don't have any document about the FOOPS extension now, but
  1602. probably by the end of the year. I will send it to you as soon as possible.
  1603.  
  1604.  
  1605. What: Release 2.0 of OBJ3 is now available
  1606. From: winkler@csl.sri.com (Timothy Winkler)
  1607. Date: 6 Apr 92 08:35:40 GMT
  1608.  
  1609. Release 2.0 of OBJ3 is now available!
  1610.  
  1611. Improvements in this version include some language extensions and additional 
  1612. theorem proving features.  In addition, an effort has been made to speed up
  1613. the implementation; rewriting is often twice as fast as in the original
  1614. implementation.  We are including the AKCL patches from the University of
  1615. Texas at Austin in the distribution, which are necessary for maintaining the
  1616. portability of OBJ3 and also improve its efficiency.  In addition, we are
  1617. distributing a SPARC version of OBJ3.
  1618.  
  1619. OBJ3 has pattern matching modulo associativity, commutativity, and identity.
  1620. New: the system automatically computes conditions for rules involving matching
  1621. modulo identity that are used to prevent obvious non-termination problems.
  1622.  
  1623. Also new to this version of OBJ3 is a facility for controlled rewriting. This
  1624. provides substantially increased support for the use of the system for
  1625. equational theorem proving.
  1626.  
  1627. To receive the OBJ3 distribution tape or an OBJ3 license, send a request
  1628. to:
  1629.  
  1630.            Judith Burgess (OBJ3)
  1631.            Computer Science Laboratory
  1632.            SRI International
  1633.            333 Ravenswood Ave.
  1634.            Menlo Park, CA 94025-3493, USA
  1635.  
  1636.         Telephone: (415) 859-5924
  1637.         Fax: (415) 859-2844
  1638.             email: obj3dist@csl.sri.com
  1639.  
  1640. Be sure to give us your postal mailing address.  Then we will send you the
  1641. OBJ3 Information Form, and License Agreement, with instructions on how to
  1642. fill them out.  (A KCL license form will also be included.)  When you return
  1643. them to us, appropriately filled out and signed, we will send you the tape,
  1644. somedocumentation, and, in case you are requesting a tape, an invoice for
  1645. $150.00 plus any required taxes.
  1646.  
  1647. If you already have an OBJ3 license, then you don't need to get a new license,
  1648. but, if you are requesting a tape from SRI, you are asked to pay the above
  1649. distribution fee.
  1650.  
  1651. It is also possible to get a license for OBJ3 at no charge from SRI and then
  1652. get the OBJ3 distribution itself from some third party also having a license.
  1653.  
  1654. Jose Meseguer, Timothy Winkler, and Patrick Lincoln
  1655. Computer Science Laboratory
  1656. SRI International
  1657. 333 Ravenswood Avenue
  1658. Menlo Park, California 94025, USA
  1659.  
  1660. Joseph Goguen
  1661. Programming Research Group
  1662. Computing Laboratory
  1663. Oxford University
  1664. 11 Keble Road
  1665. Oxford OX1 3QD, United Kingdom
  1666.  
  1667.  
  1668. APPENDIX F  Magazines, Journals and Lewsletters
  1669. ===============================================
  1670.   ACM OO Messenger
  1671.   ACM OOPSLA
  1672.   ACM SigPlan Notices
  1673.   Smalltalk Report, The (see above)
  1674.   Far more to be added...
  1675.  
  1676.  
  1677.