Home
The Toolkit for Online Communities
17103 Community Members, 1 member online, 2339 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : Working notes on OpenACS 6 proposals

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

Icon of envelope Request notifications

Collapse
Posted by Joel Aufrecht on
http://www.collaboraid.biz/extranet/openacs/file-storage/view/OpenACS%206%20RFC%2esxw

Posted so that we have something on paper before the Heidelberg meeting.  Very much a work in progress.

Collapse
Posted by Malte Sussdorff on
I skimmed through the document and it looks really interesting. Question: Is there a reason (apart from lack of time), why you did not put it up in the projects area of openacs.org ?
Collapse
Posted by Rocael Hernández Rizzardini on
can you post it in another format?
pdf, doc, html ...

TIA

Collapse
Posted by Tom Jackson on

I converted it to plain text and posted it at http://zmbh.com/oacs/

Collapse
Posted by Lars Pind on
Collapse
Posted by Don Baccus on
I guess one of the things that has really bothered me about a bunch of proposals that have been floating around is that they do not acknowledge existing functionality.

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 :)

Collapse
Posted by Joel Aufrecht on
Yeah, very few of the features proposed are wholly new.  For most of them we want to finish existing functionality, or improve or make compatible existing functionality (example that's not in the proposal: acs-lang has one table of locales, with a five-character key field, and the content repository has another, with a four-character key field.  One day these should be merged) or just document stuff that's been in the code for years but isn't used much.

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.

Collapse
Posted by Jade Rubick on
First of all, kudos for proposing some directions for OpenACS. This is an ambitious document, but I like the overall direction.

* 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).

Collapse
Posted by Tom Jackson on

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?

Collapse
Posted by Joel Aufrecht 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".  For multiple inheritence, polymorphism, etc, let's leave that out of this dimension until there's a need for it.
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.

Collapse
Posted by Don Baccus on
As this document evolves, then, I'd like to see the distinction between new functionality and the repair/extension/refactoring/etc of new functionality made explicit.  In some cases this will take detective work (which I'm willing to help on, BTW), in some cases just summarizing knowledge which isn't widely shared.

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.

Collapse
Posted by Dave Bauer on
Tom,

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.

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.

Collapse
Posted by Don Baccus on
Actually the parent_id change, while talked about frequently over the past three years and part of the changes many of us have talked about making, may not've been TIP'd with Timo's package_id TIP, have to double-check. It may've been left out to keep the package_id changed at the bite-sized nibble level of effort so it could get done quickly.

Anyway, my vision of how these columns work, which I've held for a long time now ...

  1. context_id

    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.

  2. parent_id

    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.

  3. package_id

    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 :)

These are fairly complex changes but only due to (as is so often true) the need for upgrade scripts. But ... today you have to dissect a package to see if it's overloading context_id as the physical parent_id, or package_id, or providing its own parent_id, or confusing itself by doing some mix of two or even all three of the above. We'd be rid of that at last.