Does anyone find the FTP support in Whidbey counter-intuitive?
I'm going to start by explaining why I think it has to be counter-intuitive followed by some more general questions about the operation of the API.
The WebRequest model is based around disconnected operations. Basically, no state is maintained and the sole purpose of each of the existing request classes is to perform some command, close the connection, and forget that anything ever happened. That works fine for both Http and File operations. If you need state, you bolt it on using the cookie crap for Http, and don't even worry about state using the file stuff, because you don't need it. Now, plugging a stateful protocol into this model can't be easy. That means no matter how you slice it, FTP as built into the request model is going to be hard to use, or at least no extremely intutive. Now, you could build a nice wrapper class so as to hide the request model (hint, hint), but otherwise the glaring stateless model is there and it eats away at the stateful connection provided by FTP.
Now, I'm not even sure what the new FtpWebRequest is capable of. I've tried a number of things with it, for instance, setting the Method property between calls to GetResponse. That doesn't appear to work and I get some bogus errors there. I've also tried setting a method that is not defined by FtpMethods but that doesn't seem to work either, even though the documentation says it should. There appears to be some mapping code in the back-end that throws an ArgumentException.
When all is said and done, I'm left creating a brand new FtpWebRequest for every command I want to run. I think this is probably how the API is meant to be used, but I'm still inclined to want to re-use the FtpWebRequest over and over again. Perhaps it can be re-used, but only if you issue the same command? That appears right, since I am able to do the same list command over and over again with the same request object. If one request per operation is required that means I'm going to have to do a lot of work. Let's look at a basic file download process.
FtpWebRequest->Create(serverUri)->Method(List Stuff)
FtpWebRequest->Create(serverUri + some directory)->Method(List Stuff)
FtpWebRequest->Create(serverUri + some directory + some file)->Method(Download File)
It takes three requests properly built in order to download a file. In FTP this would just be a series of DIR or LS calls with some CD or CWD calls to get to the appropriate directory location and finally a GET command to grab the file. The FTP model enables me to get my file with a single connection to the FTP server, where the FtpWebRequest model appears to use quite a few more.
Now, I hope that on the back-end each of my requests is getting mapped to a single connection to the FTP server. That is always a possibility. If so, then I need some more commands people. First, why is there a PrintWorkingDirectory or PWD command if there is no CWD or ChangeWorkingDirectory command? Why is there no Close or Quit command so that I can shut the connection down explicitly if it is being left open? Should I be using the KeepAlive property to manage the connection by issuing a bogus command like PWD with the KeepAlive set to false in order to shut down and active command connection from a previous series of commands?
Beta, Beta, Beta is the mantra I adopt when looking at these things. I can't really assume things are going to stay the same, but I also can't assume that certain features aren't already baked and complete. The FTP features for instance have everything you need to interact with an FTP server in a very basic manner. Even assuming a disconnected operation you can always format enough requests to get all of the information you need from the server. At this point, with the API in such a state, I'll assume some changes are going to be made. Net Classes team, if you read my blog, hook me up with some divine guidance!