> > Most annoying part of the protocol to be frank ;-) Hence if there were
> > mandatory filters, I'd do something like:
> > connect mesg
> > -> reply
> > getFeatures (protocol requires I believe)
>
> Nope, only the connect message is required.
Saved a message then ;-)
> > setFilters
> > -> reply features
> > ->record anything
> > -> filters okay
> > [set internal parser replies to use this]
>
> You could do this, but you have to be careful about when you enable the
> filters. The server too will have to be careful (of which tpserver-cpp isn't
> yet) to make sure that synchronised.
Not that hard... anything sent _after_ the filters message will assume
it's on, all replies after will too. Just a check of sequence number...
> > > Although.... you probably don't want to pipeline around login.... (state
> > > change).
> >
> > Depends on how much you hate round trips... ;-)
>
> True, but it will save bandwidth if you wait and the the reply is fail.
Don't care... don't notice anyway. Worst case is fail to login:
- Reply from server is a lot of fail frames...
Bandwidth, even over GPRS is minimal. Done right, with minimum packet
sizes and the like, it probably costs an insignificant amount.
> > If the amount of time required to fix the client is that drastically
> > different, then the change to the server would be to add that client to
> > a blacklist.
>
> Except if there is a client from outside our immediate project, or (heaven
> help us) a commercial client with a bug in it. Just look at the various
> provisions in Apache for working around broken HTTP/1.1 implementations
> (early versions of Java springs to mind).
Blacklist. Fail frames with the message "Tell your vendor to get their
finger out, and fix this".
Anyway.. lets hope TP gets so popular this is an issue, and you can tell
me that my uncompromising position needs to face up to reality. ;-)
Regards,
nash
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
