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.
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.
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.
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.
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.
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)
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.
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.