[sldev] Roadmap: 1.19.0 Viewer

[Lawson English]

Argent Stonecutter wrote:
> On 2008-01-09, at 07:44, Latif Khalifa wrote:
>> And how about implementing what everybody really wants, a check box 
>> saying "do not receive IMs from this group".
>
> Hell yes.
>
> Or how about something that every IM program in the world has: "log in 
> offline"?
>
> When you "log in offline" you don't show up as logged in to IM, to 
> "friends", to "give inventory", on the web, nothing. People 
> interacting with you through any interfaces that don't involve being 
> actually present in-world get the same response as if you're offline. 
> If you do anything that involves the IM system (including accepting 
> inventory from people not in the same sim, sending IMs, and so on) 
> then you go online (after a warning dialog). So you can, you know, log 
> in to build without having 3000 IMs from people who have been waiting 
> to pounce, and without having to play games with alts and tripping 
> over permissions and making sure that you don't create prims in the 
> wrong account for stuff you're going to sell...
>
> NO, BUSY MODE AND "ONLY SHOW ONLINE TO FRIENDS" DO NOT COUNT, OK? Busy 
> mode is *especially* useless, and having to go through your friends 
> list and reset who you're going to show as online with when you want 
> to go in and out of offline mode is (a) horribly time consuming, and 
> (b) probably going to lag the hell out of the asset/presence servers.
>
> Sorry about shouting. But this has been a sore spot for... eek, 
> getting on years now.
>

ARegent, I've been documenting how the protocols work, and I've spent 
the last week trying to understand Group IM.

The (horribly not filled in) description of the UDP packet for group IM 
can be found here:

https://wiki.secondlife.com/wiki/ImprovedInstantMessage


The flow to get to that point, as I understand it, is:

perform login, get seed capability, start sending packets to establish 
UDP circuit. Send packets to establish agent presence in your login 
simulator, get (at least) a ruthed avatar into teh world, then send an 
IMprovedInstantMessage packet with a Dialog byte value of 15 to request 
a group IM session.

THEN go to EventQueueNext cap and poll incoming events for the 
ChatterboxSessoinStart Event (or whatever it is called), THEN start 
sending and receiving IIM packets for that particular group. Its a 
bloody mess. Right now, what you ask for requires a ruthed avatar to be 
sitting in a simulator someplace.



Contrast that with the upcoming group IM procedure that Donovan LInden 
outlines in his comments below. The difference is startling and will 
make tweaking the system far, FAR easier:


http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/

[reference to article snipt]

* the seed capability can give you another seed capability into another 
service (solves the seed capability requiring global knowledge problem)

- the login service gives you an agent domain seed capability

- the agent domain seed capability gives you a region domain seed 
capability (if the agent chooses to enter a region)

* capabilities are usually requested at the beginning of a “session” 
with some entity and then used repeatedly (thus you do not need 2 http 
requests per request during normal usage)

- a user wants to log in to just group chat:

- request the group chat seed capability from the authentication 
service, and then request the GetNextMessage and SendMessage 
capabilities from the seed cap

- repeatedly invoke these GetNextMessage and SendMessage capabilities 
for the duration of the chat session with the server