| Prev | Chapter�15.�Kernel Documentation | Next |
|---|
By Pete Su
+A major goal in OpenACS 4 is to unify and normalize many of the core services of the system into a coherent common data model and API. In the past, these services were provided to applications in an ad-hoc and irregular fashion. Examples of such services include:
General Comments
User/groups
Attribute storage in user/groups
General Permissions
Site wide search
General Auditing
All of these services involve relating extra information and services to @@ -20,7 +20,7 @@ of the application's data model - in order to enable certain generic services. The term "object" refers to any entity being represented within the OpenACS, and typically corresponds to a single row within the -relational database.
The OpenACS 4 Object Model must address five high-level requirements that +relational database.
The OpenACS 4 Object Model must address five high-level requirements that repeatedly exhibit themselves in the context of existing services in OpenACS 3.x, as described below.
Object Identifiers for General Services
Generic services require a single unambiguous way of identifying application objects that they manage or manipulate. In OpenACS 3.x, there are @@ -49,7 +49,7 @@ OpenACS application had to manage access control to its data separately. Later on, a notion of "scoping" was introduced into the core data model.
"Scope" is a term best explained by example. Consider some -hypothetical rows in the address_book table:
| ... | scope | user_id | group_id | ... |
| ... | user | 123 | � | ... |
| ... | group | � | 456 | ... |
| ... | public | � | � | ... |
The first row represents an entry in User 123's personal address book, +hypothetical rows in the address_book table:
| ... | scope | user_id | group_id | ... |
| ... | user | 123 | ... | |
| ... | group | 456 | ... | |
| ... | public | ... |
The first row represents an entry in User 123's personal address book, the second row represents an entry in User Group 456's shared address book, and the third row represents an entry in the site's public address book.
In this way, the scoping columns identify the security context in which a @@ -119,13 +119,13 @@ Relation types are themselves object types that do nothing but represent relations. They can be used by applications that previously used user/groups for the same purpose, but without the extraneous, artificial -dependencies.
The Object Model package is a combination of data model and a procedural +dependencies.
The Object Model package is a combination of data model and a procedural API for manipulating application objects within an OpenACS instance. The OM allows developers to describe a hierarchical system of object types that store metadata on application objects. The object type system supports subtyping with inheritance, so new object types can be defined in terms of existing object types.
The OM data model forms the main part of the OpenACS 4 Kernel data model. The -other parts of the Kernel data model include:
Parties and Groups
Permissions
Each of these is documented elsewhere at length.
The data model for the object system provides support for the following +other parts of the Kernel data model include:
Parties and Groups
Permissions
Each of these is documented elsewhere at length.
The data model for the object system provides support for the following kinds of schema patterns that are used by many existing OpenACS modules:
Object identification is a central mechanism in the new metadata system. The fact that every object has a known unique identifier means that the core can deal with all objects in a generic way. Thus the only action required of @@ -215,7 +215,7 @@ 8/24/2000).
The data model should include a notion of pair-wise relations between objects. Relations should be able to record simple facts of the form "object X is related to object Y by relationship R," and also be -able to attach attributes to these facts.
The API should let programmers accomplish the following actions:
60.10 Create a New Object Type
The object system API should provide a procedure call that creates a new +able to attach attributes to these facts.
The API should let programmers accomplish the following actions:
60.10 Create a New Object Type
The object system API should provide a procedure call that creates a new object type by running the appropriate transactions on the object system data model. This API call is subject to the constraints laid out in the data model. We call this operation "instantiating" an object.
60.20 Create a New Object Subtype
The object system API should provide a procedure call for creating @@ -260,7 +260,7 @@ application's data model. In other words, it should be easy to "hook into" the object model, and that ability should not have a major impact on the application data model.
Note: Is the API the only way to obtain values? How does -this integrate with application level SQL queries?
| Document Revision # | Action Taken, Notes | When? | By Whom? | ||||||||||||||||||||||||||||||||||||||||||
| 0.1 | Creation | 08/10/2000 | Bryan Quinn | ||||||||||||||||||||||||||||||||||||||||||
| 0.2 | Major re-write | 08/11/2000 | Pete Su | ||||||||||||||||||||||||||||||||||||||||||
| 0.3 | Draft completed after initial reviews | 08/22/2000 | Pete Su | ||||||||||||||||||||||||||||||||||||||||||
| 0.4 | Edited, updated to conform to requirements template, pending freeze | 08/23/2000 | Kai Wu | ||||||||||||||||||||||||||||||||||||||||||
| � | Final edits before freeze | 08/24/2000 | Pete Su | ||||||||||||||||||||||||||||||||||||||||||
| 0.5 | Edited for consistency | 08/27/2000 | Kai Wu | ||||||||||||||||||||||||||||||||||||||||||
| 0.6 | Put Object ID stuff first, because it makes more sense | 08/28/2000 | Pete Su | ||||||||||||||||||||||||||||||||||||||||||
| 0.7 | Added requirement that knowledge-level objects must be moveable between
+this integrate with application level SQL queries?
|