Re: [Phpwiki-talk] GroupWikiPage

[Jeff D. <da...@da...>]

On Wed, 16 Oct 2002 11:57:28 -0700
Joby Walker <joby@u.washington.edu> wrote:

> Jeff Dairiki wrote:
> >>By "closed" and "open" I ment to distingish 
> >>between the "GroupGroups page" or "search for /^Group/" methods.
> > Aha!  I would vote strongly against supporting both.  We already have
> > a bad enough case of "creeping featuritis".  Pick one a go with it.
> 
> It actually isn't bad and would have no overhead to implement things in 
> multiple ways. 

My complaints about "creeping featuritis" don't really have much to do
with performance overhead issues.   The two big issues I see are
maintainance/debugging, and general simplicity or lack thereof....

Maintainance: the more ways to do things (code paths) there are
the more likely it is that someone (e.g. me) will break one of those
code paths without noticing it.  If we had a (better) test suite,
this would be less of an issue.  Currently we seem to have constant
problems (and support requests) with bugs that show up e.g. only
when USE_PATH_INFO is off, or when a certain theme is selected, etc...

Remote diagnosis of problems is generally made more difficult, too, when
there are lots of ways to do

Simplicity:  Currently any user documentation we have is lagging way
behind
our feature-set, so users already have to learn how to do things either
via code inspection, guessing, or word-of-mouth (word-of-email,
word-of-wiki)...  Introducing a new feature that can work in a variety
of ways, I think, just adds to the confusion unnecessarily.


Of course this doesn't mean that all new features are bad.
But, in this case, introducing multiple group page paradigms doesn't
really seem to me to add much functionality or usability.


 
> Once, I fix a couple things I'll post my lib/WikiGroup.php (which will 
> not be linked to by anything), so you all can get a look...

Cool!

> So with no "Group" magic name should 
> groups be allowed to have anyname?

Other than the issue you bring up (below) I don't see why not.
(User pages aren't named UserJeff...)  (And there's always the
i18n issue: GrupoCampagnolo?)

> This is frought with problems,

Yes, you're right, it is.  Still I don't really like the
magic list syntax --- I can't really think  of better
alternatives though...

> 1) If a WikiWord is used and that page does not exist.  The group could 
> be compromised by the creation of a user with that WikiWord for a name.

Oof. Yes.  Don't do that.

This problem may show up in other cases, too: what if an administrator
deletes a user (and user page)?  Then (if automatic account creation
is enabled) anyone can usurp that name...   Not sure it's a major
problem, but worth noting...

> 2) It looks like a non-homepage can be compromised and turned into a 
> homepage by adding a CategoryHomepage and then trying to login with that
> 
> name.

Okay.  Maybe the CategoryHomepage idea is a bad one...  Let's fallback
(for the sake of discussion) to detecting user pages by the presence
of user meta-data.

> 3) Every link needs to be investigated to determine if it leads to a 
> homepage -- this determination currently requires parsing the page, so 
> instead of parsing one page to determine a group's members it will 
> require N pages be parsed (where N = number of links on a group page).

A) I don't see why a page parse is needed to detect a home page.
   It should only require looking at the page meta-data.

B) In most cases, it is only of interest if the current (viewing)
   user is a member of a particular group (the group of the requested
   page).  In that case, we already know that the username if interest
   is a valid user (and therefore a valid userpage).

> 4) Without the "Group" magic word a homepage can be a grouppage as well,
> 
> which means that user A could not link to user B's homepage without 
> adding B to A's group.  Which seems overlimiting...

True.  One solution is "don't do that".  ("Doctor, doctor...")
(Another solution would be not to allow that: ignore any groups which
have the same name as a user.)

Jeff