Forum OpenACS Development: Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites

Collapse
1: Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites
Posted by Peter Vessenes on 05/17/01 04:36 PM

Wizards

Hi 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 Forking

Secondly, 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 Woes

Finally, 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?
Collapse
2: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Don Baccus on 05/17/01 09:00 PM
I wrote a long answer but my IP Masq box choked while digesting an 250 megabyte tarball of an oracle installation I'm moving from one machine to another.

So here we go, a bit more briefly I'm afraid:

Wizardry

I 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.

Subsites

Ouch, 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 Woes

They'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...

Collapse
3: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Michael Feldstein on 05/17/01 09:08 PM
Wizards are a fantastic idea. If you could walk a site admin
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.
Collapse
4: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Peter Vessenes on 05/18/01 12:00 AM
Okay, it's up here. 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. In any event, the documentation is there, Don -- you can just install it, and go to /doc/acs-subsite to read about the differences.

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, (tigre@ybos.net), if you need someone to praise or bug.

Collapse
5: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Peter Vessenes on 05/18/01 12:10 AM
On the groups, we've discovered a number of interesting things, which I'll record some of here for posterity --

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.
You've now got a subsite with one uber-Admin, who can add people to the Admins group, and a set of Admins who can add members, as well as administer the subsite.
Collapse
6: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Don Baccus on 05/18/01 12:59 AM
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.
Collapse
7: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Peter Vessenes on 05/18/01 05:06 PM
Of course we want this rolled in and released, but we don't have time right now to sort out the versioning issues, so I just released it with a key and version number next in sequence. I'm not convinced this is the best way to release it; hence my plea. As far as availability, this code is released; I just don't want this particular module traded around as subsites-4.2.1 to the general public without a little more work on our side (code review) and a better community strategy for how to release these things. Does that make sense?
Collapse
8: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Don Baccus on 05/18/01 05:55 PM
Yes, it does, and thanks for the clarification, Peter.
Collapse
9: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Dan Wickstrom on 05/18/01 06:40 PM

Relational Segments

Relational 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.

Collapse
10: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Michael Feldstein on 05/18/01 07:14 PM
It sounds to me like relational segments will be useful for sites
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.

Collapse
11: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Dan Wickstrom on 05/18/01 07:45 PM
Not only will you not see any benefit for small sites, but the complexity might actually get in your way and slow your development progress.  This might be balanced by other areas in openacs 4.x, such as the new db api or the templating system - both which should boost productivity in large or small site development projects.

For small sites, using something like openacs 3.2.5 or acs 3.4.10 (if you need oracle) might be more appropriate.

Collapse
12: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Jerry Asher on 05/18/01 08:16 PM
As Dan suggested earlier, I think some common patterns will fall out of this eventually and be abstracted into higher APIs that will be easier to learn, implement and maintain.

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.

Collapse
13: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Don Baccus on 05/18/01 08:19 PM
The question I have is whether or not we can hide the complexity for modeling the old group member/role approach behind an appropriately-designed package with a decent admin UI, one that the site designer could install optionally if it were adequate for their site's needs.

That group member/role seemed adequate for a lot of smaller, simpler sites.

Collapse
14: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Dan Wickstrom on 05/18/01 08:38 PM
It should be possible to create a package that emulates the old group/member role approach, or since we need to redesign the admin pages anyway, if might be a good idea to just build something like that into the admin pages as part of the redesign effort.
Collapse
15: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Michael Feldstein on 05/18/01 08:48 PM
Speaking of wizards, groups, members, and roles, (Hey, are we
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.
Collapse
16: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Peter Vessenes on 05/18/01 10:47 PM
Michael, this is the sort of stuff we'll probably be working on in the next month or so for one of our clients.. I think that the simple UI is something we're pretty good at as a company; we'll be sending a load of stuff out to the community in the next few weeks, so keep your eye out.

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.

Collapse
17: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Don Baccus on 05/19/01 02:46 AM
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.
Collapse
18: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Michael Feldstein on 05/19/01 03:04 AM

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.

Collapse
19: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Stephen . on 05/19/01 05:42 AM
I think the above descriptions of relational segments are a little confusing and inaccurate.

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.

Collapse
20: Response to Some 4.X questions, and comments, including adding wizards to the package spec and complaints about subsites (response to 1)
Posted by Dan Wickstrom on 05/19/01 03:32 PM
"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."

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.