> I had a larger reply to this, but somewhere it got lost. > > Using a client/server model has no heavyer requirments than a p2p based > mode. Nor is it any complexer, but it will allow much easyer to > participate in client/server based conferencing.
I still dispute your opinion on this, a client having to act as a server can create more problems than it solves IMO (as already discussed), and IMO its not really any easier to participate in. > I also think building p2p based conferincing into the protocol from day > one is unnecisarly complex, that should belong in an extention in any case > then. Have you changed your mind on the complexity? you say at the top of this email that its no complexor to implement p2p than it is client server, seems a bit of a contradiction. > It's odd though, that you completly put aside the arguments you tried to > make about 1 on 1 chat, when you talk about conferencing. Namely, limited > bandwith (in the case of 20 people talking this would be almost 10 times > as much as as c/s based) and lack of mixing capabilities (even if your > pocketpc does have that much bandwith it'll have to mix 20 channels!). Its just as bad for the client acting as the server (in bandwidth terms) as it is to go p2p, also I would disbute that it would be 10 times as much bandwidth for the rest, adding silence detection (which you seem to have oddly put aside and ignored) reduces the p2p bandwidth use massively, also as I have shown previously the mixing requirements are less on p2p clients than on the "server client". Also having a server client creates a single point of failure which you also seem to have completely put aside, there is also the latency issue that you have yet to address and until you do address this satisfactorly I will not be convinced by your strange need to make this client server mode only, for which you still havent provided sufficent reason. Richard _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
