> > >
> > > 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[?]
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 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 ;-)
> 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.
Once the other server starts to support padding, I'll move to padding.
Which means my client will work correctly on ARM ;-)
Regards,
nash
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
