one> 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> of the client will assume the role of the server.robustness
Could not agree more. This is exactly what I was to suggest - simple in end-user implementation, consistent and uniform. A good start forand reliability.
Im still not convinced this is really needed for P2P mode, it means much
higher requirements for the server role client, and im not sure we should be
requireing the extra complexity of having to combine the two streams into
one, what if both clients where pocket pc's ?
There is no such requirment. The only difference is in handeling the XML. Rather than doing this P2P style (with no client taking the role of server) on of the clients will have to play "server". But ofcourse the only thing it will "serve" is it's own audiostream, and the only client it will serve is the other "peer". However, supporting this will mean that with the same spec and implementation you can also participate in conferences! Wether those are hosted on a component or on another users machine who has a more advanced client that supports mixing.
Again, the only difference is in handeling the XML. Wich I think would only be a bit different, not quite harder to do or more complex.
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
