MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: Conferences


> Not really, since the booking is keyed to the list,
> all that is really needed is some way of permitting him to edit the list.
> if he is granted a feature object when he is booking the room, the feature
> object could have permission, rather than the booker.

That's similar to the original idea I had:
I thought of having a basket of keys, one for each room. A person who wanted 
a room would take the key (which would be the only way to use the room's 
exit), and use it. There were two problems:

     a) What if people don't return keys?
     b) It only allows ONE person to go thru - not his/her whole party.

I like your system, since the key itself will have the permissions.

> Thus, it becomes a matter of controling acess to the feature object, 
(which
> can only be owned by one person) rather than controlling access to the 
room
> which can be used by many. As long as the person gives the feature object
> to some active player, the room remains open. If the feature object is
> relinquished, or all the players sign off, the room is returned to its
> original state, and the feature object reverts to storage.

This is the complex bit - ensuring that the feature object is not "lost" by 
being stuck with one player. Would I be correct in saying that in the 
player's exit function, I'd move the object back to its original spot?

Also - what happens when two parties want to book two separate rooms - who 
uses the object? One for each room?

> If you find you are running out of conference rooms, simply have it
> automatically revert if the room stays empty of players for an extended
> period.

Yep, although I don't forsee that problem.....yet :)

Avi
Home | Subject Index | Thread Index