In the beginning, Oskar and Scott said, "Let there be Client," and it was good.
Later, Tavin said, "Let there be multiple backend implementations of Client, while trying to preserve the consistency of ClientEvent semantics," and Mr. Bad and GJ were cast out of the bier garten before six o'clock :( My point being that... now we have FNPClient, FCPClient, and even InternalClient which I'm ready to commit to the experimental branch. Combine that with the evolution of the protocol, and I am finding that the old semantics just don't _quite_ make sense anymore. Let's concern ourselves with the ClientEvents RequestFailedEvent, RequestCompleteEvent, and RequestSuccessfulEvent, plus two new ones that had to be added for FCP, DataNotFoundEvent and RouteNotFoundEvent. * RequestSuccessfulEvent. This one isn't produced at all, and is totally unnecessary because we have StateReachedEvent (i.e., you reach the state DONE). So I vanquish him! * RequestCompleteEvent. This one is only produced in one place, and again it's redundant because we have StateReachedEvent (you could go to DONE or FAILED). So I want to vanquish him! Ok? * RequestFailedEvent. Hmm.. toughie.. the thing is that it makes no sense for FCPClient or InternalClient, which use DataNotFoundEvent and RouteNotFoundEvent. In fact it's wedded to the FNP implementation b/c it contains a Message member and methods for examining that Message. So I think we should get rid of it and just use DataNotFoundEvent and RouteNotFoundEvent all through. A user of FNPClient can always inspect the actual Messages being passed, using SendEvent and ReceiveEvent. OK? One more thing now. These are the Request states as they stand: INIT, PREPARED, REQUESTING, TRANSFERRING, DONE, FAILED. Why do we have TRANSFERRING? We already have TransferStartedEvent, TransferedEvent, and TransferCompleteEvent. Plus, the fact of restarted requests means you end up having to switch back and forth b/t REQUESTING and TRANSFERRING -- yet in FCPClient and InternalClient you can only go through the Transfer* states once, which makes it very difficult to logically get to TRANSFERRING a second time if the request is restarted.
