Re: [FSP-devel] FSPv3 design notes

[Leon T. <fa...@gm...>]

On Tue, Jul 20, 2010 at 2:14 AM, Radim Kolar <hs...@se...> wrote:
>  FSP needs to stay simple protocol. If we make long feature list then
> it will be complicated to implement. Look for example at HTTP/1.0
> protocol, its very simple.

One nice part about HTTP/1.1 is how is falls back to HTTP1.0
gracefully. For simple clients and servers it's a really simple
protocol, for more advanced users it's more complicated. They're not
exclusive.

> can you give an example on it? it should be enough to have it IMAP like.
> List of keywords with optional argument.

Most of all, it's useful to allow simple users to use a simplified
dialect of the protocol while allowing faster, more complicated users
to use a more optimized dialect. Everyone wins.

> Better to add possibility to query minimum retry times. Client can
> always do slower.

Being able to query retry times combined with a ping command would be
enough I think.

> I do not like idea of Windows. we will need reinvent wheel and do TCP
> style ACKS and SACKs. Its much less coding to use TCP instead. Keep it
> simple like FSPv2 is in style REQUEST -> REPLY.

I don't think it would be useful to copy TCP. I do think that it would
be useful to allow more than one request/reply to be on the wire at
the same time. The protocol doesn't have become a lot more
complicated. What if we'd add the concept of channels and allow the
client to use the current paradigm within each of the channels? Simple
users using just one channel would work exactly the same as the
current system does, while more advanced clients can scale up their
speed if the server allows for it.

Regards,

Leon