[435] in Zephyr_Comments
class/instance mechanism
raeburn@ATHENA.MIT.EDU (raeburn@ATHENA.MIT.EDU)
Sat May 19 20:43:13 1990
Is it sensible to keep this exactly-two-level hierarchy, or would it make
more sense to generalize? Would an arbitrary hierarchy (netnews style) be
better?
The use of the <class,instance> tuple provides us two key features: access
control, and filtering of messages.
The filtering can be better accomplished with the availability of more
than two fields (only one of which can be wildcarded). As an appropriate
example, consider the filsrv notifications for NFS servers. Two
subscriptions are entered for each file system attached -- one for the
whole file server, and one for the target directory being mounted. If you
want to take a partition or disk offline for some reason, you have to
notify everyone using the machine, and tell them how to figure out if
they're using that partition.
With hierarchical subscriptions, I could enter one subscription to
filsrv/cyrus/u2/lockers/games
and get notices about
filsrv/cyrus
filsrv/cyrus/u2
filsrv/cyrus/u2/lockers/games
It's a bit more difficult to generalize it to AFS, but I think it could be
done. It would also provide for
message
message/consult
message/consult/rs1
A similar scheme would be to use a single flat namespace, with wildcards.
I say it is similar to the arbitrarily hierarchical scheme above, because
in many respects it is simply a differences in representation.
Wildcards seem necessary. We could use the UNIX style ?/* wildcards, for
a simple scheme, or we could use something like Multics did, where "*"
matches all or part of one dot-separated component, and "**" matches any
number (even zero) of complete components, in addition to the "?" form.
Thus, "olc.**" would match all OLC messages, and "olc.rs1.*" or
"olc.*.new_question" would match "olc.rs1.new_question". It may make some
aspects of wildcard handling easier if there are fewer components to deal
with (i.e., dot-separated strings versus characters). I doubt we would
need the "?" form, so that simplifies things.
Access control can be done with a pattern-matching scheme: Have a file
which maps "filsrv.**" to "filsrv.acl", or just use the first component of
the target name, and add in the mode (xmt, &c) to get the ACL file name.
The recipient field still needs to be independent, I think, and the opcode
field isn't part of the addressing scheme (though perhaps olcd could use
something like "olc.rs1.new_question", if people ignore some of the
olc-class messages based on the opcodes).
It would mean quite a bit more server work, but as Mark Eichin pointed
out, there are a lot of common cases that we can optimize for.
Thoughts?
