Generic "Presence Awareness"

[Rick_Bullotta]

Hi, Cocomo team.



Any plans to add the concept of a global roster (e.g not tied
to a room) and associated presence awareness APIs for it?
Associated with that, I suppose, would be a persistent list of a
user's "contacts" in addition to the global roster.



Just a thought....



Rick

[Raff_]

Interesting idea but I am not sure we have all the pieces to
implement it completely.



Currently the presence information is associated to a room
(the room is the only entity that knows which users are in) and we
don't have an easy way to "federate" rooms or exchange presence
information between them.



Actually we do keep track of all users currently logged in
(and which room they are supposed to be, even if potentially they
could not be in the room yet or have just left) but we are not
keeping per-account information (i.e. assuming you want to build an
IM service I would guess that for security purpose we should only
let you check presence for users in your account).



Anyway, this question/request comes up once in a while so
we'll keep it in mind.

[Clive_Howard]

Hi,



I would like to add my support to Rick's suggestion and was
going to post the same thought myself. AFCS is great once you start
creating rooms but prior to that it would be extremely useful to
know which of your users are online so that they can then decide to
join a room (to chat and so on). Just as you would experience in
most IM programs.



We have an application that would benefit greatly from AFCS
but to integrate it we would need to solve the initial user
presence issue first. Therefore it would be perfect if Adobe
implemented a "lobby" where all users can be detected prior to
entering a room(s).



This would probably need to be implemented differently to
rooms however as if the number of users grew to hundreds, thousands
or more then iterating a user list (as you do with room user lists)
clearly would have problems. I think Adobe has this type of
functionality in other products (Live Cycle) so can be done.



Thanks,



Clive

[Raff_]

Presence (and notifications) it's an interesting feature for
a service like AFCS, because of the way we implement accounts.



I mean, if you have an SDK account that you use to runs your
applications, would you want a system that gives you "global"
presence (i.e. access to every user in every account) or limited to
only your account ?



If you think global presence is required, how would you
identify users that are not in your account ? Especially if your
applications, or other applications for which you may be interested
in some users implements external authentication in such a way that
user ids have nothing in commons ?



If you think you could live with local presence, then maybe
implementing the lobby as an application running in your account
may not be generating heavy traffic/processing because you would be
dealing with a much limited number of users.

[Clive_Howard]

Thanks Raff,



My thoughts on implementation would be to not have rooms
directly within an SDK account but have lobbies and then rooms.
Alternatively each application would have its own SDK account.
Personally I would prefer this anyway as having all apps against
one SDK account seems problematic to me (but that's another post).
Either way it allows the developer to group rooms by application.



I believe that many people will find they have the same
situation as Rick and I whereby we have an app with a large number
of users. Some of these users will want to break away and form a
room but there is no way to know who is online at any current
moment so that they can choose to enter a room.



It could be that this is not part of AFCS but another Adobe
service. Live Cycle does this I believe but that requires hosting,
something hosted in the cloud that does this could compliment AFCS
and be very useful.



Thanks for responding,



Clive

[RickBullotta]

A few things could help:



1) A persistent list of user "friends", so that within an
account, individual user(s) could have these list(s) saved and
could be used for "roomless collaboration" (basically, enabling
AFCS to act as a generic IM client). Only "room-based" chats and
collaborations would be persisted.



2) A "generic room" or "lobby"



3) A live list of who is connected and live in any and all
rooms, including the lobby (with the ability for a user to cloak
themselves if the account/room is configured to allow cloaking)



4)

[cosmacol]

We implemented this feature using the room itself as the
global roster, and using groups to dinamically manage "sub-rooms".
Managing and creating groups in code is also easier (and faster)
than dealing with rooms.



Cosma Colanicchia

[Clive_Howard]

We considered that approach but if you have hundreds or
thousands of users then the room can become unmanageable especially
if you have to iterate lists of users. I am not sure how one
handles the fact that each user can see a different subset of all
users (as in contacts or friends in IM). By using rooms a user
would need to be a member of an ever changing number of rooms based
on people coming and going. Almost like creating a room for each
users with their friends in it but then each of their friends would
have their own room as well. If anyone has ideas about how to
manage this using rooms that would be great.