On Thu, 2008-01-03 at 16:24 +1100, Brett Nash wrote: > > Nash, did this clear up your problem - or does it still stand? > > > > > > 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. > > I still don't like right of refusal. In particular mandatory filters > are pointless, to `implement' a mandatory filter I just need to set the > flag, and then refuse to allow it when asked. Protocol allows this, and > it totally misses the point. Just for reference I'm not just thinking > about tpserver-cpp, but about future servers, and even proprietary > servers who implement the protocol. > > Maybe such filters need to be flagged with 'can't be refused' or > something weird. But that leads back to your gz/bz2 example - both > mandatory, but both is silly... > > I fear the solution is for each filter we specify the semantics > specifically, and allow the server to say "go read the spec" if it is > invalidated. Else we lead into to protocol craziness... > > Regards, > nash > > >
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
