[101] in Moira
discuss and hesiod
daemon@ATHENA.MIT.EDU (qjb@ATHENA.MIT.EDU)
Sat May 5 15:02:41 1990
From: qjb@ATHENA.MIT.EDU
Date: Sat, 5 May 90 15:01:45 -0400
To: discussers@ATHENA.MIT.EDU, moiradev@ATHENA.MIT.EDU
The topic of using hesiod for discuss meeting locations has come
up many times before but has always been rejected for good
reasons.
The following idea occurred to me today, however. Instead of
using hesiod for information in the way that we do for attach,
use it instead as an addition to the current system. I propose
the following:
* Meetings announcements should still contain the hostname of the
meeting so that meetings can be used as soon as they are
created.
* Add meeting and goto meeting should consult hesiod first and use
it if available. If that fails (because, for example, the
hesiod record has not [yet] been created for the meeting), fall
back on the current system.
* If there is a discrepency between what hesiod says and what
meeting announcement says, ignore what the meeting announcement
says. (That way, forward files could be erased after hesiod has
been updated when meetings are moved...)
* If there is a discrepency between what hesiod says and what is
in the .meetings file, update the .meetings file and go with
what hesiod says.
* Add to the add meeting command a way of adding a meeting
directly from hesiod. This way, you could tell someone to
: am my_new_meeting
or maybe if we wanted to (although I see no reason to)
: am hesiod:my_new_meeting
The problem with all of this is that all meetings known by
hesiod must have unique names. Also, a meeting not known by
hesiod cannot share a name with one that is known.
This is related to the issue of doing acls with moira as well.
In order to do the acls with moira, moira will have to keep
track of what meetings are on a given host. Why not organize
the information in a way so that location can be served as well?
(I realize that one is a host->meetings map and the other is a
meeting->host map, but still...)
Finally, the queries to add, delete, or update meetings can have
an acl other than dbadmin. Perhaps discuss meeting records can
have owners so that if an admin creates a meeting for someone,
that person can then update the meeting if necessary.
Comments?
