Re: Feature Request. Topic Group Parameters...

[John Griffith <griffith@sfs.nphil.uni-tuebingen.de>]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

    LMI> John Griffith <griffith@sfs.nphil.uni-tuebingen.de> writes:
    >> How about asking the user what should be done?
    >> 
    >> Allow topics to have group parameters specified on them, but only use
    >> these to update group parameters on actual groups when moving groups
    >> into topics or changing topic-specified parameters.
    >> 
    >> When changing a group parameter on a topic, ask the user if all groups
    >> should inherit this parameter, or whether s/he would like to go
    >> through each group individually, showing old values and the possible
    >> replacements (if they're different).  (Like the initial subscription
    >> sequence.)

    LMI> I think this sounds a bit annoying.  I would prefer having clear rules
    LMI> for topic parameter inheretance instead of requiring lots of user
    LMI> input when editing parameters.

I agree that this could get annoying, especially if you constantly
change things like I do.  So here's some ideas on possible rules.

Here's an example:

  t1
    g1
    g2
    t2
      g1
      g3
  t3
    g2

1.1) First of all it seems that if you're going to have rules to
     determine inheritance, then one should be that parameters
     specified on the group are always preferred over those specified
     on topics that it is in.

1.2) And lower topics are always preferred over higher ones, so g3 would
     take t2's parameters over t1's.

2) Another possible rule could be that if a group (g1 above) occurs in
   two topics (t1 and t2) one of which is an ancestor of the other,
   then the parameters of the lower group should be preferred.

3) The problem is, of course, what to do with a group (g2) that occurs
   in two topics (t1 and t3) which are not in the ancestor relation.

3.1) The most restrictive rule would be to disallow g2 to be under t1
     and t1's sister t3.  But I for one find that too restrictive.

3.2) Another possibility is to give every group a "home" topic.  Then
     that group only inherits from it's home topic, and possibly from
     ancestors of its home topic.  This seems fairly powerful, simple
     and easy to understand.

3.3) A less restrictive possibility would be to allow users to specify
     a precedence ordering on topics to determine which topics should
     win in a conflict.  However, it could be quite tricky to ensure
     that the user's rules completely avoid conflicts.

3.3.1) The simplest way would be to require a total order on
       topics. There could be a buffer with the list of topics, and
       the user could move these around.  You could limit the number
       of topics to be moved around by only displaying those that
       actually have parameters specified on them.

3.3.2) You actually don't need a total order, the user could specify a
       partial order on topics, but then the partial order would have
       to be checked to make sure every group's parameters could be
       uniquely determined.  I think this would require computing the
       closure of the partial order, which (I think) is O(N^3) where N
       is the number of topics.  Could be slow with lots of topics.
       Even if there were very good error messages in the case of
       conflicts, this could be very annoying and confusing.

The idea of having a home topic seems to be a nice balance between
simplicity and power.  This could be augmented with possible
inheritance from supertopics as in rules 1.1 and 1.2.  Then you could
think of part of the topic hierarchy as defining a parameter
inheritance hierarchy, and as part of it defining a hierarchical
presentation of groups.  Also, I think rule 2 wouldn't be necessary
since either t1 OR t2 (exclusively) would be the home of g1.

It seems like there should be some help to the user to recognize that
they've, for instance, just put a group in a topic which will cause it
to inherit total-expire.  A lot of damage could be done very quickly.

It would be nice if you could display the parameters associated with
each topic and group in the topic hierarchy and to mark groups when
they occur in their home topic.