Hi Chad,
1. Yup, only account owners are able to create rooms. This
would include your server, which can call HTTP APIs to spawn rooms.
2. There are APIs to get the set of rooms on the service
(I'll let Raff speak more to this). That said, it's likely that
your server should be keeping track of what it's spawned and who it
has routed to those rooms.
3. See my answer above - when your server serves up a SWF,
it can use FlashVars or some other means to tell that SWF which
room to connect to. If your server is keeping track of what rooms
it has built and who it has routed where, you can build this
functionality.
4. This depends - "knocking" is one mechanism that forces
someone to allow guest users in, but mostly I'd manage this through
obscurity, using the methods described in 2) and 3) above.
For the workflow you describe, I think you could use a
separate room (or several rooms) as lobbies. From there, every
client in your lobby would ask your server for the list of active
rooms (rooms that still have capacity for more people). If they
wanted to create a new one, they'd ask your server to do so, and
send a message to everyone in the lobby to re-fetch the set of
rooms. For joining a room, they would need to ask your server the
URL for the room they chose, and connect to it. Your server would
keep track of who has requested to join, and potentially, if more
than 10 users have done so, take that room off the list of "active"
rooms.
For the "creator can boot people" workflow, what you're
looking for is the ability to make the person who requested a new
room to be made the "owner" of that room. To do this, you'd need to
use external authentication. See the section on "deploying
applications" in the developer guide for more details.
In short, this all seems possible to me.
thanks
nigel