Forum OpenACS Development: Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites
WizardsHi all, we've been working on a new 4.2tcl site, and learning some interesting things. One thing we've done is added the concept of a wizard, which a package can run on mount. We've updated a small number of places in the core (is this acs-kernel package?) to do this.
Is there an area to put the patches for those who don't have commit privs?
Subsites and the Request Processor, and ForkingSecondly, we have been puzzling for some time over how best to do subsites. For key modules in the core, there are a number of ugly versioning problems that come up when someone tries to edit them, and replace the existing versions. Here's an example:
You want a module which provides subsite features, like templating, etc. BUT, you also want to create your own hierarchy of custom scripts for the subsite. You might want two different types of these modified subsites on the same system.You have a problem. If you change the subsite module, and increase the version number, you are breaking the development path for the subsite module, and essentially forking, even though the changes are specific to one site. Also, it won't be clear to people which subsite module does what. And, this method won't support two types of modified subsites on the same system.
On the other hand, if you change the package key, you have a problem, because the Request processor walks up the node tree to determine the nearest package with a "subsite" package key for purposes of figuring out who does the templating. This is a general problem; packages and the request processor do not use the "provided services" information for a package to determine how to interact with a package, they just use the package key. This is short sighted, and non-optimal.
Can we have a discussion about what it would take to change the system to use services information, rather than package keys? A naive method would add at least one select per request, which is a bummer. (But, not the worst thing that's been done in the ACS 4 in terms of performance.)
Relational Segment WoesFinally, we are killing ourselves on the groups data model, and the concept of relational segments. Can anyone here explain why these are better than member-in-a-role system we had in 3.X, given the extra overhead of using them?
So here we go, a bit more briefly I'm afraid:
WizardryI like this idea, yeah. You could drop a patch into the SDM, but this is probably too extensive for that. I think of SDM patches as being more useful for localized patches that fix a single bug or an a very small feature to the system.
So perhaps you could put the patch file somewhere I could grab it via anonymous FTP? I'm very busy with client work at the moment, but perhaps Dan Wickstrom or one of the other core hackers could look it over.
SubsitesOuch, yeah, this sounds like a real problem that needs discussing. I have no ideas off the top of my head, perhaps something will develop here ...
Relational Segment WoesThey're better than member-in-a-role because you can express more complex relationships. Whether or not you need to frequently enough to make dealing with any extra complexity worthwhile is an altogether different question, of course!
Dan Wickstrom probably knows more about the parties and groups stuff than anyone else who's currently an OpenACS 4 volunteer...
through the customization process every time a package in
instantiated (with the option for them to quit out if they'd rather do
it through the regular admin interface), that would be a big win.
One additional enhancement we made was to add a column which lists the package type next to the name in the site map. This is handy if you don't want to name everything after the packages.
This modification was written by Titi Ala'ilima, (email@example.com), if you need someone to praise or bug.
If you want to create a subsite that will have a group which can be considered admins, and a group that can be considered members, you need to undertake the following steps. (Marc Hildenbrand can follow up here if I get it wrong).
- Create an Application Group associated with the package_id. You can't use the normal group::new interface, you need to use the application_group::new proc.
- Grant admin on the application group to at least one party.
- Create two groups, one called Members, one called Admins.
- Grant admin on members to the Admin group.
- Grant admin on the subsite to the Admin group.
- construct a composition relationship between the application group, and each of the two groups.
- Add the admin party on the application group to the Admins group.
I'd like to make a public plea that this not be widely distributed, since it may be overwritten by ArsDigita's Subsite package releases at some point.I'm confused - I thought you were offering the patch for possible inclusion into OpenACS 4? Also ... future aD releases aren't likely, and Tcl 4.3, if it comes about at all, will be very limited in scope. We'll pick what we like and ignore the request if it ever happens.
Relational SegmentsRelational segments are just a way of defining relations to groups, and they consist of unique pairs of group_id's and rel_type's. So a relational segment might be something like the members of group A, or the components of group B.
So far, the only use that I've seen for this in acs 4.x is to define constraints on membership and composition relations. Such as constraining membership relations between users and groups, and constraining composition relations between groups.
Constraints can be specified, so that you can say that I want all members of group B to also be members of group C. Or you can say that you want group X to be a component of group Y. You can also have more than one constraint on each 'side' of a relationship, and you can extend relationship types and add your own attributes to a relation, so relation types and their constraints can be arbitrarily complex.
Not only can you describe something like the member-in-a-role approach used in acs 3.x, but you can describe and constrain other types of relationships used in acs 3.x that were thrown together in an ad-hoc fashion for each new package. The advantage to the acs 4.x approach is that the relationships are described and accessed using a consistant interface.
So the price for this higher level of abstraction, is a longer learning curve and poorer performance due to the complexity of the implementation, balanced against having a consistent interface that supports arbitrarily complex modeling of relationships. It's hard to say now if it is a win, having not tried to apply the new relations concepts to new module development or to a new site development project, but it's likely that for most development projects, a small set of patterns will emerge that are useful when using the relations/constraints/segments code in acs 4.x.
acs 4.x definitely requires more of an up-front investment in learning, before you can become productive when using the toolkit. This will be turn-off for alot of people who were originally drawn to the acs toolkit, because it provided alot of functionality, and yet, it was easy to learn.
with complex, interrelated permissions. Dynamic publishing (for
a large site) and knowledge management strike me as two
areas where there are potential benefits. Another example might
be in a large community with many groups and sub-groups. For
example, in an educational setting, it might be useful to be able
to have a student registered as a member of a class workgroup
and be automatically parented into the class and added to some
larger academic community discussion group. (It would save a
lot of clicks for admins.)
That having been said, it doesn't sound like sites managed by a
relatively small number of people will see any real benefits from
the more complex system.
For small sites, using something like openacs 3.2.5 or acs 3.4.10 (if you need oracle) might be more appropriate.
The eGroups pattern for one (or is that the MCI circles pattern?) would be useful for many sites small and large where you want to let your members create objects (files, mailing lists, databases) readable, writable, etc. by other members or guests from the net.
Anyway, I have great hopes that after the straight port, the community will come up with other ways to encapsulate/view/use the group/parties/people/relations model.
That group member/role seemed adequate for a lot of smaller, simpler sites.
playing Dungeons and Dragons here, or what?), would it be
possible to build wizard utilities that help admins set up the
required groups and import members into roles when
intantiating a package? One of the most confusing aspects of
the ACS admin (particularly around modules with complex group
management, such as intranet) is having to go to the separate
groups admin page, figure out which groups to turn on and who
to put into them, and then go back to the admin pages for the
packages you wanted to work on in the first place.
I agree with Don, I think that the groups UI is going to need a simplified implementation for small sites. This actually won't be too hard; there are a few key concepts you need to grok to do the hard work for the user, but we seem to be there internally now, so that should help the community in any event.
One of the most confusing aspects of the ACS admin (particularly around modules with complex group management, such as intranet) is having to go to the separate groups admin page, figure out which groups to turn on and who to put into them, and then go back to the admin pages for the packages you wanted to work on in the first place.Hmmm...what I find most confusing about ACS 3.x administration is that after you figure out all the above, you then learn that the use of groups and roles for different packages are all different! Some packages can be administered by the sysadmin, others can't. Some have a special admin group, others use membership in the package's overall group with an admin role. Eck.
Hmmm...what I find most confusing about ACS 3.x administration is that after you figure out all the above, you then learn that the use of groups and roles for different packages are all different! Some packages can be administered by the sysadmin, others can't. Some have a special admin group, others use membership in the package's overall group with an admin role. Eck.
Yeah. That too.
Using Michael's example of students in a class modeled as an acs group, you might create a new relationship type 'learning' for students and another type 'teaching' for professors. Both students and professors are now members of the group, and you can treat them as a whole for purposes of permissions, spam etc.
It is also useful to treat the students and professors as seperate groups, for example to assign professors some extra privilege such as bboard admin. You could create a new group and add the professors, making sure to keep membership in both groups in sync, or you can use relational segments.
Relational segemnts define the members of a group based on some existing relationship they have to another group.
But this has nothing to do with relational segments. You're just talking about relations. If you wanted, for example, to spam all of the members of a group that had a 'learning' relation with the group, you wouldn't need to use relational segments.
" It is also useful to treat the students and professors as seperate groups, for example to assign professors some extra privilege such as bboard admin. You could create a new group and add the professors, making sure to keep membership in both groups in sync, or you can use relational segments."
Again this sounds like something that you could do with relations, maybe you could elaborate on how relational segments would be used in this case.
" Relational segemnts define the members of a group based on some existing relationship they have to another group."
I think that you can assign that meaning to a relational segment, but as I said before, relational segments only define relations to groups. Look at the data-model for relational segments:
create table rel_segments ( segment_id integer not null constraint rel_segments_segment_id_fk references parties (party_id) constraint rel_segments_pk primary key, segment_name varchar(230) not null, group_id integer not null constraint rel_segments_group_id_fk references groups (group_id), rel_type varchar(100) not null constraint rel_segments_rel_type_fk references acs_rel_types (rel_type), constraint rel_segments_grp_rel_type_uq unique(group_id, rel_type) );
The essence of a relational segment is a (group_id,rel_type) pair, and the parties/relations data-models stand-alone without the use of relational segments. Defining members of groups based on some existing relationship is accomplished with the use of Relations - Not relational segments.