[sldev] 1.19.0 Group Chat
ordinal.malaprop at fastmail.fm
ordinal.malaprop at fastmail.fm
Tue Jan 8 15:33:17 PST 2008
Thank you for the more technical details there. I am sure that even
the least technical observer is aware of group IM spam, too, and would
thus be very keen on the idea of being able to turn it off for
particular groups. This will meet with lots of "yay! good job, LL!"
sort of reactions.
However: I really really _really_ advise you not to put this in until
the auto-join-on-login feature is implemented. Firstly it is a big
change in UI behaviour without a way to return and that is always an
issue, regardless. Secondly, there are lots of groups where one
_always_ wants to be aware of IMs. As I stated before, there are
estate lists for estates that I have controls over, where people
announce griefer attacks and sim problems. I _need_ to have access to
these, and so every time I log on I would have to actively join. This
will be very irritating very quickly. And I am a very poor example
here - I am not that sociable and I'm sure lots of people will have
far more need to access different group IMs than I do.
Unless there is a really significant need to put the change in group
IMs before the server flags allowing auto-login PLEASE don't do so. If
you do, it will turn a "oh great! LL has done something cool that is
useful to the community!" change into "dammit! LL has screwed
everything up again! I used to have that and it doesn't work now!
<insert random LL flame here>"
On 8 Jan 2008, at 23:23, Jonathan Wolk wrote:
> Just thought I'd pass along some info as to LL's decision to
> remove some "features" of group chat in 1.19.0. The main reasons
> for this was to make group chat (and conference chat) opt-in instead
> of opt-out as there are countless complaints about "group IM spam"
> and frankly, I agree with the complainers about this one.
>
> Current behavior
> ----------------------------------------
> The current behavior is as follows:
>
> When you double click a group IM session to "start" it one of two
> things happens.
> 1) The group chat session doesn't exist, so a "new" session is
> started in which all online group members are looked up and added to
> the session. This group member lookup is the cause of much DB load
> and there is currently no way of opting out of this. You get the IM
> regardless if you want it or not.
> or
> 2) A group session exists and you are just added to it. No
> members are looked up, you can potentially join a session with 1
> other member in it.
>
> The user currently has *no* way of knowing what scenario will
> happen and this is very inconsistent. The user has no way of opting-
> out of group IM. Even if you get a group IM and close it it is
> possible that you will receive another group IM later (if there was
> a session that just ended and the code goes down path #1 again, you
> get the IM regardless).
> Also, when you log in, you are added to any existing group chat
> "passively" in the sense that you do not have to open your tab to
> receive an IM (or a little group voice chat pop up). Doing this
> adds minimal load to the system but is also opt-out. You'll receive
> any IMs to the group after you log in regardless whether you want to
> or not (unless you open and close the tab, but even then you may
> still get a group IM if a "new" session starts up and all online
> members are looked up.....sigh).
>
> Future Behavior
> -----------------------------------------
> Changes were made in 1.19.0 to remove the group member lookup on
> new session start in an effort to decrease DB load, to make the
> group chat opt-in rather than opt-out, and to make the behavior more
> consistent.
> In 1.19.0 (or at least when the servers go out) when you start a
> group IM, you are always added to an existing group chat regardless
> if it exists or not (though the group may be empty. The
> inconsistent feature of "IM all online members of the group" is
> replaced with "IM all online members of the group who chose to opt-
> in to group chat".
> A change was also made to remove the auto-login in an effort to
> make group chat opt-in rather than opt-out. I am working on a way
> to make the auto join on login a simple checkbox (as mentioned in
> this list previously) though the previous way of having these be
> "passive" will not work (though there may be another way of making
> them passive).
> I hope this clears a few things up.
>
> -Jonathan Linden
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
More information about the SLDev
mailing list