On Wed, 16 Jan 2008, Brett Nash wrote: > > > > 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. > > Probably bad terminology. I thought there were going to be filters that > all servers must implement: > - String padding > - Compression maybe[?]
I was not under that impression. I thought that all filters would be optional to implement. > It seems strange to require them, but be able to always refuse them. > Which is essentially my point. > > > > > 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. > > [/me notes that yes it does, and it's annoying in a client which > pipelines _everything_] I would hope that you don't pipeline around the initial connection, ie, check that the other end is indeed a TP server. The clients should be able to, without pipelining do the following: connect frame <- reply getFeatures <- reply setFilters <- reply <set filters active> then start pipelining. Although.... you probably don't want to pipeline around login.... (state change). > > > > 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 > > Personally I'd say for the last case: > - Let the client be incorrect, fix it in the client. Work arounds for > other bugs suck... this is one area open source can get advantage ;-) What do we do about the client in the mean time? In particular if it's like tpsai-py and automatically re-establishes the connection after it is drop for a good reason (like lost synchronisation, corrupted packets, etc). > 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
