Jason L Tibbitts III <tibbs@math.uh.edu> wrote:
Sounds great! Could you please include this text in the Mj2 source tree
so that the idea won't get lost?
-- NB.
> Last night while trying to sleep I figured out an interesting way to do
> nested lists relatively cheaply.
>
> Each list has a variable: master_list. In it you put the name of the list
> the current list is under in the hierarchy. Multiple lists can be under a
> single master. (We'll also need to track the dependencies in the other
> direction using 'slave_lists', but it is possible to do this
> automatically.) All of the lists that you can address are real lists, not
> ephemeral objects created from database joins.
>
> When an action (say, zubscribe) is performed, the core routine works its
> way up the tree and does what's appropriate. Join a list on a far branch
> of the tree and automatically be put on the other lists back to the root.
>
> This can also be used for config variable inheritance, user flag
> inheritance (although this requires the flag structures to change) and
> other things. I think it would actually satisfy many of your requirements.
>
> But there are three things I especially like: it is probably the simplest
> way to do this (code-wise), it has zero impact on regular operation (if
> 'master_list' is undefined, you don't have to do anything extra) and it
> imposes no explicit naming convention. I can have (as I do now) lists
> fvwm, fvwm-workers and fvwm-announce and have fvwm-announce be the master;
> joining either fvwm or fvwm-workers automatically puts you on
> fvwm-announce. This is something I think would see a whole lot of use were
> it implemented.
>
> Note that this is essentially orthogonal to the issues of having a single
> address with the list name in the subject (still just needs a different
> front end, easy to write) and doing per-user thread exclusion (just needs
> an extension of the already available per-user filtering stuff, pretty easy
> to write).
>
> Issues:
>
> Assume the following structure:
>
> list-root
> / \
> / \
> list-a list-b
>
> How does unsubscribing work? If you leave list-a _and_ list-b, are you
> removed from list-root? Does the behavior change if you joined list-root
> explicitly rather than implicitly by joining a leaf? (If so, we need to
> track just how you came to join a list, which is not difficult.)
>
> Inheritance of subscriber data (i.e. if the 'replyto' flag in list-a is
> "uninitialized" then we look to list-root to see if the user has it
> defined there, and so on up to the tree until we fall back to the
> default) is hard. Really hard, because we need that stuff at delivery
> time when we don't want to go plowing through bunches of databases (and
> we don't have the necessary information anyway). It is possible to have
> a 'set' on a list-root automatically set things in the leaves, but I'm
> not sure that's appropriate. It is also possible for a set on list-root
> to change the settings on list-a form "uninitialized" to "uninitialized
> but inheriting a value", which may be the only "reasonable" way to do it
> (for certain values of reasonable).
>
> Who's going to write it? Not me, not right now at least. Still,
> figuring it out was an interesting way to pass the time. I'd appreciate
> it if someone who was interested in doing this would think it out
> further. If this actually takes care of most of the requests then I'm
> willing to think about coding it _after_ the base software has been
> released. Priorities and such....
>
> - J<
>
References:
|
|
