I agree with you. The Software will go in that way. If only two people are conferencing it will use the p2p. If there are more, it will switch to the server mode and will go ahead. This will only take - lets say a second - so it is not really disturbing.
Perhaps the spec can be written in such a way that there is always a server and a client, and that in the case of 2 people wanting to talk one of the client will assume the role of the server. Connection between client and server will then be done by SI, to the best ability of both the clients (I'd encourage SOCKS5 / UPnP / UDP-NAT-friendly solutions over other things, but one could for example fall back on SOCKS bytestreams if they don't work or if the client is too simple).
Maybe if you have a little more advanced client (since it will have to do mixing and such), and a broadband connection you could even host your own little conference, or perhaps you could administer the "mini-server" on someone else's client if you don't have the best connection or your client doesn't support being a(n advanced) "mini-server" using a configuration/admin protocol as would be defined in the spec.
Corperations, Jabber admins with a lotta free bandwith, paid for servers, VoIP bridges, etc. could use real components that support many simultanous conversations and conferences. And these users can use the same configuration/admin protocol as the average home users. (with some extenstions for payments etc. perhaps)
This way we get the best out of two worlds, optimal flexibility, and all within the a single spec, and we'll avoid lot's of overlapping implementation.
Best Regards,
Carsten Breuer
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
