Ticket ID: |
#169 |
Bug Report: | $problem_report_165 |
Reported From: | the Courtyard ($courtyard) |
Reported By: | No One ($no_one) |
Reported On: | 01-Dec-1998 |
Resolved: | UNRESOLVED |
Claimed: | UNCLAIMED |
Bug Group: | |
Summary: | $mail_list is a parent of $mail_ui |
| |
$mail_list is a parent of $mail_ui, which is not very good from the inheriting POV. Maybe it would be better to add a variable pointing to the user's mailbox instead of having the user being a mailbox itself.
| |
On 02-Dec-1998 Bruce ($user_bruce) Comments: To elaborate a bit more on the thoughts that Broesel and I were discussing at that time ...Why shouldn't $mail_ui be a command module instead of a parent, and then break $mail_list out so that a $user object points to the mail list associated with it. For example: $user_bruce<$user>,mailbox = $mail_list_user_bruce.This would require some changes to $mail_lib.parse_mail_recipient(), $mail_ui, and not sure what else. | |
On 06-Dec-1998 Bruce ($user_bruce) Comments: Well, looking into this, $mail_ui requires per-user data. This isn't possible with a command module is it? Could command modules be changed to allow for that? Also, looking at the code on $mail_ui, I don't see why it done as a child of $mail_list. Any enlightenment? | |
On 07-Dec-1998 Brandon ($brandon) Comments: Its loosely based on the MOO model--poor decision. There are really two issues covered in this PR, a: why are users mail_lists, and b: what about $mail_ui being a command module. B will likely happen when the 'big change' happens moving all users to $user etc. A will likely stay the same because its inherent to the whole design--this system is not folder based, making that sortof change can impact the whole system, potentially opening holes in a lot of places--i'd rather just see it rewritten from the ground up, than tinkering with things like that. | |
|