Forum OpenACS Q&A: Re: Working notes on OpenACS 6 proposals

Collapse
Posted by Don Baccus on
I've been thinking about object parentage in terms of dimensions. Each object in the system has a location in at least two dimensions, and each dimension is a tree. One is the object type dimension: each object has one and only one object type, and that object type is directly descended from the "base object".

Let me don my compiler writer/language designer hat for a moment ...

No. Though I've suggested that it would be convenient if object types were objects at times, objects are not object types. An object's type is an attribute of that object, and the fact that we implement a hierarchical form of subtyping , rather than a flat type space, does not change that fact.

Object types are hierarchical because of the type system. Objects are neutral in this regard.

The second dimension is the "basic dimension." Every object has a place in this dimension for two purposes: so that it can be located by a user, and so that it has a permission context. (This would replace the context_id regime. E.g., currently every object is in a package, and inherits permissions from the package. Instead, any object could be in any other object and inherit thusly.)

WHOA! Let me correct some misunderstandings...

  • Objects do not necessarily inherit permissions from a package. This is often a convenient way to manage permissions for simple packages - notes, for instance - but the inheritance system doesn't require this, not in the least. More complex packages like forums don't implement permissions inheritance this way, i.e. forum threads inherit from the forum object, not the package object.
  • We've already decided to split the inheritance of permissions and physical parent into two fields. In practice many packages do this already, some "cheat" by overloading context_id to serve both needs, but I consider those poorly written. We do NOT want to go back to a scheme where an object's physical location in the object tree determines permissions inheritance. We DO want to generalize the parent_id field maintained by many packages (sometimes called package_id in simple packages with a simple object structure) by moving it to acs_objects.
  • Every object can already be "within" another object (I assume you mean "a child of") and inherit permissions from it. We're talking about normalizing something a bit more complex - an object should be able to inherit permissions from one object even though it's located physically as a child of another object. This is done today by many packages (the CR for instance), we just want to standardize the practice and put an end to overloading the context_id as many packages have done. This has been TIP'd and approved and either shouldn't be included as a proposal for new functionality or should be marked as a TIP'd/approved work item and described in a way compatible with the TIP.