@swhitley org.xmpp.presence.md - multiple client issue

[neuroscr]

I see a sever flaw in this annotation. It's only coming the perspective of "is the user on ADN". Since you can access ADN from multiple clients, how can you ever be sure (without user interaction) to mark it as offline. Many web apps don't received a proper user interaction when they're done (users typically just close the window/tab).

I suggest we extend this setting per client and possibly allow multiple clients. There would be great benefit in knowing what devices/clients the user is currently active on (and not).

I'd like everyone to weigh in and discuss how we best can handle identifiers for a users, devices and clients as we're likely need to apply this to more than one annotation.

[swhitley]

It's an interesting thought, and I hadn't considered automation. The original annotation was designed to require user interaction.

I'm not opposed to exploring the idea, but my first thought is that it will be overly complicated to maintain per client/device settings. The maintenance of the array would be difficult and probably confusing. There will be entries that should expire. How will the expired entries be cleaned up?

Using the current annotation, a client could help automate the status change (e.g. on exit), but a dialog should still be presented so the user is aware that a change is being made. We'd want the user to be aware that he or she is still responsible for the status since other clients probably won't offer the automation.

[neuroscr]

Even with user interaction, consider the case of two clients. I'm active in both and then I mark one away, the other client looses state and won't know unless it's polling. Which isn't a great requirement.

In an IM environment being able to route messages to the correct device, this scenario is important. However on ADN, they handle all of this for us. So I guess it goes back to the main question, what's the use case of Presence on ADN?

[33mhz]

I think I'll use it when viewing profiles, and make it easy to access in my client. Possibly default to "away" on load and periodically. I'm looking at presence for whether people are available to play games together.

[neuroscr]

I think the more modern way is to use messages/channels. Hello and Bye messages to denote presence. Clients would have to have some type of idle timeout to write the Bye if the user stops using the app for a bit and then resume the presence when they're back.

[33mhz]

And just ping a "hello" message every _ minutes in the channel?

That makes sense. Do a one or two minute update interval, and interpret 5 minutes as "away", and then 8 or 10 minutes as "inactive"?

[neuroscr]

I would avoid a ping. Just a message per state change: Hello//Bye. Do the ping stuff in the client itself but don't write to ADN. For example, if the client is idle for 15 minutes, send bye and next interaction remember to say hello again.