Forum OpenACS Q&A: Working notes on OpenACS 6 proposals
Posted so that we have something on paper before the Heidelberg meeting. Very much a work in progress.
pdf, doc, html ...
I converted it to plain text and posted it at http://zmbh.com/oacs/
We have a lot of existing functionality that has been poorly exploited, but there seems to be widespread misunderstanding of what functionality actually exists.
Just one example:
Feature: Architecture improvements Skinny-storage You can add new attributes to any object via the UI.
This isn't an architecture improvement, the object attribute SQL API allows for the addition of new attributes to any object. Has all along. Works fine. Tastes great.
So at most this is a UI improvement. However, beyond that, the CMS UI allows for the addition of new attributes for any objects that happen to be content objects. You may recall we've already approved a TIP for 5.2 to merge content object and "plain" object attributes code, to make the SQL and Tcl API and underlying datamodel the same. Doing so will mean that the attribute addition UI will work for objects of all kinds - though still buried without refactoring in a damned unobvious place, our abandoned CMS.
I noticed a good ten or twelve other examples in the proposals, out of perhaps a couple dozen proposals.
I guess my feeling is that you can't properly discuss where you'd like to go in the future without an accurate assessment of where you are today. Basic navigational concept :)
We also need to identify why some features aren't used much, and what sort of systemic or procedural changes are needed so that we can stop re-(half)-implementing the same things every year or two.
* I like the point about configuration versus customization, and like the goal of moving towards configuration rather than customization.
* I also like the idea of incremental implementation. Yes, let's do this gradually.
Can I propose an extention to the notes use case:
People can be assigned to notes. Any number of people can be assigned to a note.
Multiple notes can be edited at a time (scalable interface). I can edit three notes on one page.
The reason I add these to the use case, is that I think one of the problems with ad_form is it doesn't address these cases very well. Using multiples is very hard to do in my experience. Multiple dates, for example, is rather nightmarish.
I'm also thinking about the data soup idea in relation to the most recent application I've developed: project-manager (I'll be releasing version 1.0 this week or next week, by the way. We're using it now at my workplace. Yes, we finally upgraded from ACS to OpenACS!).
So I can see the advantage of being able to put all sorts of objects in my projects and tasks. It would be nice to be able to put blogs and pictures and files and so on inside a Project or Task. I'm not so clear on how the system will know how to display everything.
I've read all the data soup articles, but I guess I'm "core hacker" enough to get how it will work.
(Note: the XML was too small for me to read, by the way).
I'm unclear on the meaning of parent_id, and why an object can have only one of these. Can you re-use objects, or can only pages reuse objects? If I upload a photo in photo-album, can I re-use the same photo somewhere else?
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.) This dimension should also be single-parent unless there's a strong reason otherwise, which I haven't seen yet.
Now, we want additional dimensions so we can arrange the site in different ways just by moving folders around on a tree. Do we do this with entire additional dimensions, or with symlinks, or is there a need for both? I can see use cases for each. For the first, I want to build one site map for visitors, another for customers, and a third for staff. I could do that with permissions masks, but that only lets me hide sections, not change their layout. For the second, Tom's example of putting a photo in two places is a use case. In that example, the photo should still have only one "true" home, from which permissions are determined.
Among other things this will help us measure the amount of work required, where we'll need to concern ourselves with backwards compatibility, stuff like that.
The current way to do this with the CR is to make a symlink object. Besides this there are other ways to relate an object to another. The main one is cr_item_rels or whatever it evolves into. This gives a good way to show what the related object should do with the other object.
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.
Anyway, my vision of how these columns work, which I've held for a long time now ...
This should actually disappear as it's only used as something to hang a trigger onto for permissions, and it shouldn't be overloaded as a stand-in for the physical parent_id pointer. I won't go into details here other than to say that making it disappear would force programmers to use the API to change it, it would get rid of two columns in objects (security_inherit_p), and the API could forbid errors like trying to tell the system to not inherit permissions but to also inherit them from object FOO (we have to support this now due to the overloading by several packages of context_id as the physical parent_id). I think, but am not sure, that we might see improved performance (not much, just a little) during object creation.
The physical parent of the object, the addition to acs_objects perhaps having been TIP'd already, perhaps not. Existing packages either overload context_id, package_id, or add a parent_id (content repository) so upgrade scripts would have to be written to take this into account. Fairly large job, worth doing IMO.
I've always looked at this as being primarily a convenience for the package author for those times when you want to find all the objects created by a package. For instance when you delete a package instance or when you uninstall a package systemwide. These scripts have historically been buggy and hard to write. Folks have overloaded package_id to make up for the lack of a physical parent field (i.e. notes) - historically their own private package_id but now carried into acs_objects - and, once a proper parent_id is added, this should be Strictly Forbidden :)