Discussion based notifications were poorly implemented, and discussion
based signals and timestamps were even worse at the time of this release.
At best they were pre-alpha. They have been rewritten for the next
upgrade and will (hopefully) behave more intelligently.
> 6>>> miscellaneous review items
>
> a) synonym for '/review detach'
>
> I think having 'det' as a synonym for 'detach' on /review would
> be welcomed by many.
I've been noticing this myself. (: I'll see what I can do.
> b) consulting: can't review a Client that is long gone.
>
> /review consult user Client_#1
>
> This only works if the Client is actually connected.
>
> But it would be highly useful if one could review a particular client.
I'll have to work with Christian on this, because I don't know if there's
a fixed relationship between a client number and a client's object's
number.
At best I imagine I could only narrow it down to review from any Client_#1,
not to review from a specific Client_#1.
> c) No date boundaries in /review
>
> It's hard to tell which day the messages are from when reviewing
> a discussion or buffer that's been around for some time.
We haven't forgotten this.
> g) Some people are getting Range errors.
>
> /review consult session
> (Beginning review of consult: Thu Dec 1 21:14:12 1994 EST)
> # *** (21:14) raindog is now permitted to discussion consult ***
> # *** (21:14) Kenstein is now permitted to discussion consult ***
> # *** (21:14) Kenstein is now a member of consult ***
> # *** (21:24) Client #1 has entered consulting with the problem
> # "HELP!" ***
> # *** (21:24) raindog is now a member of consult ***
> # *** Client #1 is now being helped by bp ***
> #6:reviewMessage (this == #124), line 18: Range error
> ... called from #15:showByTime (this == #108), line 26
> ... called from #2:/review, line 71
> ... called from #6:do_command (this == #124), line 9
> ... called from #0:do_command, line 5
> (End of traceback)
This has been fixed for the next release, and patches for it and a similar
problem were posted to lily-servers on Nov. 29. (Bug Reprot #7 and Bug
Report #7).
> h) /review discussion detach
>
> /review consult detach
> (Beginning review of consult: Fri Nov 18 11:40:04 1994 EST)
> # *** (11:40) System Manager is now a member of consult ***
> # *** (11:50) bp is now permitted to discussion consult ***
> # *** (11:50) bp is now a moderator of consult ***
> # *** (11:53) bp is now a member of consult ***
> (End of review of consult)
>
> This was done by someone who just entered lily for the first time and was
> never detached before. Obviously, the discussion existed before they
> entered. It looks to be exactly the same as "/review consult" without the
> "detach".
This is an intentional overloading of /review detach, intended to allow
people who use /bye to review the contents of a discussion from the time
they byed to the time they reattached. For a user who has never been on
before, this feature would show all of the review up to the first signon.
> i) Some people still get traceback errors sporadically. Easily
> reproducable once it happens to a particular discussion. It seems
> to only occur when the "time" parameter is put on /review. A
> /review discussion by itself doesnt seem to ever have any problems.
>
> I am completely uncertain why this occurs on some discussions and why
> not on others.
These errors originate from the same bug as reported in part g).
> j) when someone renames, their messages dont carry the old name.
>
> Let's say I send some messages to a discussion as "bp", then I
> rename to "atul" and send some messages to a discussion,
> then I rename back to "bp". When I review, the notifications say "bp",
> but the messages I sent as "atul" say they were sent as "bp". If I reviewed
> when I was "atul", the messages sent by "bp" show up as if they were sent
> by "atul". As I said, notifications seem to be unaffected by this behaviour.
Private, Public, and Emote events have custom handling that rebuilds the
message header and the message body. Because no history is kept of name
changes, the current name is used when the headers are rebuilt for review.
All other events are built only once and static text is stored for them.
> 11>>> What I should not leave out.
>
> Lots of neat stuff has been put in that DOES WORK. Thank you.
You're welcome.
- Matt
-----------
Matthew T. Nelson
nelsonm@ctron.com
Sales Systems Administrator
Cabletron Systems, Inc.