Anyone else got any more ideas about this? Or are we happy with the following information.
Nash, did this clear up your problem - or does it still stand? - Mithro On Thu, 2007-03-15 at 10:29 +1030, Tim Ansell wrote: > On Thu, 2007-03-15 at 10:30 +1100, Brett Nash wrote: > > > Filter negotiation will be performed in the following way. > > > > > > * Extra Id's will be added to the features frame to add > > > different filters. > > > * The client will choose which filters are used. > > > * Server has "right of refusal". > > > * Filter negotiation can not be pipelined. > > > * New "Set Filters" frame will be created. > > > > I'm confused about something... > > Why does the server have right of refusal? > > Server Load is a big one. Another one is that if the client is very slow > (IE takes 30 seconds) the list of filters may have changed. > > The client could also be asking for silly combinations (IE gz inside bz2 > inside zlib). > > > If the server doesn't want to offer a filter it should not advertise it > > in the first place. Now we get the silly circumstance I can write a > > server that advertises a list of filters, without implementing any, then > > just refuse them all. > > Yes, but that is silly :). The server needs to be able to refuse because > of stupid/silly/intentionally bad clients. _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
