+jgroup extension

[GoogleCodeExporter]

1) Is it feasible for +jgroups to allow other jgroups as members?

For instance, I might want +tech to include all the people in +code and
+build, or +rp to include +story and +wiz. This could be a 
shortcut to maintaining the lists, as well.

This isn't pressing (or even really necessary); it was just an idea I had.

2) I haven't looked at how you 'expand' the list. When someone /assigns
+wiz, does +wiz sit in the assigned-to field, or does it expand and
assign all wizzes when /assign is enacted? 

I hadn't given list expansion any thought until now - but what if I 
have assigned +wiz to a bunch of jobs, and hire a new Wiz afterward? Are
they in the assigned list if they're added to the +wiz group, or are
they TSOL until the next +wiz /assign pass?

Original issue reported on code.google.com by Fleety...@gmail.com on 21 Jan 2010 at 8:51

[GoogleCodeExporter]

1) I thought about it.  The main problem was recursion. What happens if +wiz is 
a
member of +wiz? Or if +staff is a member of +wiz and +wiz is a member of 
+staff.  Or
loops on a higher level.  It's just too hard to try to detect and prevent 
loops.  I
figure codestaff can override the &ISMEMBER attribute to reference the other 
lists,
e.g., or(u(otherlist/ismember),u(anotherlist/ismmember), etc. ), so it is 
easily done
if desired.

We might consider a "HOWTO" section of the wiki explaining some of the more 
esoteric
options like this.

2) For /assign, it assigns the dbref of the jgroup object, and only accepts one 
name
(e.g., I can only assign to +story, not to +rp an +story).  In this case, if a 
new
member joins that group and it's already assigned, it is now "theirs".

For all the other commands (source, query, tag, untag) that previously took a 
list of
players, the jgroup is expanded into the player list and then applied as 
normal.  In
those cases it's just a "macro".  Adding a new member to the group won't
tag/query/source them.

I wouldn't recommend changing this for the tags based on their structure (need 
to
individually remove members when they've completed the tag action).  
Concievably you
could for a /query or /source, but those change OPENED_BY which is typically a
"player" asking something of staff, rather than the other way around.  And would
require a lot more overhead figuring out how to mail the opener(s).

Original comment by widdis@gmail.com on 21 Jan 2010 at 9:30

[GoogleCodeExporter]

1) Yeah, true. A parent hierarchy would prevent recursion, but by then we're 
almost
at a backstage object-oriented +org system. (Hmmmm - I've got a 75% coded IC 
org 
system using parents, where if you're in an org, you're also part of the parent 
orgs,
too. We might be able to cop some of the code, if interested.)

I'll try to learn how the wiki works.

2) Okay, I get it, now. :) Closing...

Original comment by Fleety...@gmail.com on 22 Jan 2010 at 2:06

• Changed state: Invalid