Colloquy 2 Hordes - Revision 2
~~~~~~~~~~~~~~~~~

I finally decided to rewrite Colloquy, my NILEX talker clone from scratch, in
order to get around some bugs, design flaws, and the general ickyness of it.
This gives me a good oppertunity to change the architecture for, what I
believe to be the better.

Colloquy 2 will internally treat what are currently "groups" and "lists" as
the same thing - storing them in the same table, and manipulating them with
the same routines.  I propose to call these "hordes", simply to stop confusion
with current terminology (ok, they *are* groups of users, but that word's
already taken).

My aims for this architecture change are:

  1) To simplify the source code, making Colloquy more reliable.
  2) Add extra functionality and flexibility.
  3) Provide a more consistant general feel to methods of grouping
     conversation.
  4) Be backward compatible in user interface.  ie, if you don't want to make
     use of the new flexibility, the user interface appears exactly the same
     as the old one.

The most important advantage of using hordes, is that the line between groups
and lists becomes much more blurred.  Rather than you only being able to
inhabit one group, but many lists, you can be in any number of hordes you like.
Essentially, this means that you can be in more than one group at the same time.

To provide a compatible interface, some very slight semantic changes need to
be made to the user interface, but in a way everyone should be comfortable with.

Groups, will become what lists are currently, and the current group manipulation
commands (such as .gname, .lock etc) will be mapped onto list commands. The
command .group will be slightly special: It will set your "default" horde that
you will see as normal group talk is currently displayed.  If that horde doesn't
exist, it will create what could be described currently as a "transient" list,
ie one that only exists while there are people connected in it.  (It would vanish
when the last person either leaves it, or disconnects.)

This also means that you could use .group to change your default horde into a
list, making a nice alternative to what .query is currently used for.
(Although you'd nolonger see the conversation in the group you were in - I
need to think about this.)

List talk would be formatting in exactly the same way that it currently is.
If you join muliple groups, then all but your current default one will appear
as a varity of list talk.

Here are some examples:

Bob         @This is a line that was said in a group with is not your
             default. {@Cheese}

Bob         :This is a line that was said in your default horde.

Bob         %This is a line that was said in a list that you are a member
             of {Cheese}

(ie, the last two are the same as they are currently.)

There is also the possibility of allowing you to specify an alternate colour
scheme for group talk that isn't in your default.

Here is some example command usage:

  .group %Cheese        (Changes your default horde to the Cheese list)
  .group Cheese         (Changes your default horde to the Cheese group)
  .group Public         (Changes your default horde back to Public)
  .list join @Cheese    (Joins the Cheese group, while keeping your
                         default as it is)
  .list leave @Cheese   (Leaves the Cheese group.)

When using .group, you leave the horde you were previously a member of, unless
you explicity joined it with .list join.  For example, if you connect and
appear in @Public, and you then do .group Foo, then you leave @Public.
However, if you do .list join @Foo, and .list join @Public, then you can
switch between the two by using .group to set the default, but still receive
data from the other.

I'm not sure what would happen if you tried to .list leave your current
default horde.  There are several possibilities:

   1) It tells you not to be silly.
   2) You join @Public.
   3) You don't have a default horde, so you see nothing other than
      the other lists and groups you've joined.

I'm also not entirely happy with using the .list namespace to allow you
to join multiple groups, but as they're implemented as lists anyway, it
sort of feels right.  Perhaps .horde join, etc?

I welcome feedback from anyone, be it "That's evil, don't do it", to
"Oooh, lovely" to "I think you should do it this way instead."