On Thu, 03 Jan 2008, Brett Nash wrote: > 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? > > > > > > > > > > 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.
There are no "mandatory" filters, unless I misunderstand what you are getting at. > > 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... Why should a filter be flagged "can't be refused"? I can't think of any filter that would need that. The documentation already says not to pipeline around the setfilter and reply frames. > > 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... The server should only advertise filters that is supports. This could change over time if load, etc is taken into account (ie: no longer advertising compression because the cpu load it too high). Reasons that a server could refuse a filter set: - one or more is not supported (could separate temporary and permanent) - two (or more) conflict - client's implementation is known to be incorrect None of these should cause a significant problem for the client. It can try again with a different filter set, or continue using the existing set (by default, none). The filters only add low level optional features. In some ways, I wish there was a way for the server to require filters (for example, encryption). With a little tweaking to the GPR system, the failure frame could indicate what the problem(s) are. I note the only two filters defined so far is the string padding filter and the SSL/TLS filter. The string padding filter is implemented in tpserver-cpp. About 80% of the work for the SSL filter has been done as well, but it's not currently on my todo list to finish. > > Regards, > > nash Later Lee
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
