FtpWeb​Request

Why is this class named this, exactly?

The "web" is just one of many services available over the Internet, making FTP an adjacent service, not a child (e.g. WebDAV).

So why isn't it just FtpRequest? (well, considering FTP is stateful and notentirely based on the Request/Response model, it makes this even worse).

Because it inherits from WebRequest and the designers of that bit appear to have some hungarian love left. It is at least consistent with the existing FileWebRequest and HttpWebRequest, no matter how stupidly they are named.

AndyC wrote:

Because it inherits from WebRequest and the designers of that bit appear to have some hungarian love left. It is at least consistent with the existing FileWebRequest and HttpWebRequest, no matter how stupidly they are named.

I just can't wait for .NET4.0's TelnetWebRequest and IrcWebRequest

W3bbo wrote:

Why is this class named this, exactly?

The "web" is just one of many services available over the Internet, making FTP an adjacent service, not a child (e.g. WebDAV).

So why isn't it just FtpRequest? (well, considering FTP is stateful and notentirely based on the Request/Response model, it makes this even worse).

As far as I'm concerned, you answered your own question.  This isn't a full FTP client protocol.  It's strictly a Request/Response model that uses the FTP protocol.  I don't know what you'd prefer to call it, but considering what it does and how it does it, I'd say it's named very well.

GopherWebRequest FTW.

AndyC wrote:

Because it inherits from WebRequest and the designers of that bit appear to have some hungarian love left. It is at least consistent with the existing FileWebRequest and HttpWebRequest, no matter how stupidly they are named.

That's actually common practice in .Net, including the base class name in the child class name.

Doesn't mean I have to like it

It's not so bad when the resulting name still makes sense, here I don't think it does but then I'm not keen on WebRequest as a name anyway. And there are certainly counter-examples already; you get a DivideByZeroException rather than a DivideByZeroArithmeticException, for example, and you tend to use Buttons rather than ButtonControlComponents.

I'd prefer a descriptive name over an unnecessary enumeration of class hierarchy every time.

If your biggest complaint is naming I think microsoft is doing a good job. Once a class hits IL does it really matter what its named.

odujosh wrote:

If your biggest complaint is naming I think microsoft is doing a good job. Once a class hits IL does it really matter what its named.

yeah... um... no. At least they didn't call it t-s-e-q-e-r-t-i-h-s naming is a big part of a language.

It's not really a request anyway. It wraps a bunch of ftp commands:
[code]open
user
password
binary
ascii
get /path/to/file
bye
[/code]

tgraupmann wrote:

It's not really a request anyway. It wraps a bunch of ftp commands:

open
user
password
binary
ascii
get /path/to/file
bye

It's a fallacious design, to pretend something operates on a different paradigm when it really doesn't.

Same thing with ASP.NET and "Server Side Events".

odujosh wrote:

Productivity is more important than technical purity.

But I feel ASP.NET's Server-Side Events for controls are a hinderance to productivity since they clash with my developed understanding of HTTP and the stateless web.

It also makes it harder to develop truely portable and compatible webapps.

W3bbo wrote:



tgraupmann wrote: It's not really a request anyway. It wraps a bunch of ftp commands: open user password binary ascii get /path/to/file bye

It's a fallacious design, to pretend something operates on a different paradigm when it really doesn't.

Same thing with ASP.NET and "Server Side Events".

I think the goal just to make it more approachable for newbies, so you don't have to RTM for FTP to have it be useful. It was probably someones pet project that got past QA.

I am sure no one meant the pretense that your trying to create here. Its merely an abstraction that makes things more accessible and probably adds some error checking in for good measure.

Turns what could take a bit to research syntax to a trip through intellisense. Is that not a good thing ? I don't think FTP will be leaving us anytime soon.

I think the server side argument is as invalid. ASP.NET provides a good abstraction. There may be other models that will develop later. (MVC, Managed client side code, Flash/Flex, etc) Saying pure GET requests with HTML forms is better I think is throwing the baby out with the bath water.

Productivity is more important than technical purity.

W3bbo wrote:



odujosh wrote: Productivity is more important than technical purity.

But I feel ASP.NET's Server-Side Events for controls are a hinderance to productivity since they clash with my developed understanding of HTTP and the stateless web.

It also makes it harder to develop truely portable and compatible webapps.

I will agree that if you goal is to run on whatever flavor web server this could be an issue. Every project I have worked on they are more than happy to lock in on a Server platform. Even for amateurs hosting providers abound that offer both Windows and Linux Servers. (the prices are very similair and range with what support and features you want)

If you talking about browser compat. Your server platform choice does not absolve you of handling differences in browsers rendering, so this has nothing to do with choice of server side platform. All server side technologies I know of (PHP, ASP.NET, ASP, CGI) are pretty client angnostic unless it some technology dependency (javascript is a great example). Client agnostic is half the point I think. I have done a CMS (Content Management System) that a team that all used MACs used to post articles to a site using ASP.NET. So as a client you could care less if it is PHP or ASP its all abstracted away by the time it reachs you.

ASP.NET is a tool not a requirement.

Maintability may be another issue you want to look into with you line of thinking. Although you may understand what your doing it your code. Will the next guy have to base his disertation around it to understand the subtlties. I think of this as code weight. Is what I wrote documented and clear. Or do I need to take a perl class to begin to understand what @#$@$# means

odujosh wrote:

If you talking about browser compat. Your server platform choice does not absolve you of handling differences in browsers rendering, so this has nothing to do with choice of server side platform. All server side technologies I know of (PHP, ASP.NET, ASP, CGI) are pretty client angnostic unless it some technology dependency (javascript is a great example). Client agnostic is half the point I think. I have done a CMS (Content Management System) that a team that all used MACs used to post articles to a site using ASP.NET. So as a client you could care less if it is PHP or ASP its all abstracted away by the time it reachs you.

Not in my experience.

"Pure" ASP.NET is great, but it's when you get into System.Web.UI.WebControls (rather than HtmlControls) where you enter client dependencies.

Modern additions to ASP.NET like Control Adapters and Atlas/AJAX muddy the waters even more and make it harder to have a "clean" project.

I also miss VS2003's Web Application project model (VS2005 SP1's still doesn't support WebDAV). VS2003 was also faster at Remote Debugging.

W3bbo wrote:



Modern additions to ASP.NET like Control Adapters and Atlas/AJAX muddy the waters even more and make it harder to have a "clean" project.

I also miss VS2003's Web Application project model (VS2005 SP1's still doesn't support WebDAV). VS2003 was also faster at Remote Debugging.

I often wished my biggest issue with maintaining a project not I had nothing to do with was tool choice. Often it is working with hacked up solutions and debungling poor practices based on design as you go planning:). Which is a chronic problem with small teams it seems lack of formal planning with architecture. I know that may sound like a good thing but it is like lacking DNA during prebirth. How do you build an arm that talks to the shoulder if you can't agree on design?

Not sure about either of techs you mention. I use Telerik professionally, so I never had to work directly with AJAX or specifically microsofts implementation. Telerik's implementation is good as long as you don't have to AJAX accross User control lines. They are working on that for the next release with AJAX Manager Proxy, which only becomes the manager when one doesn't exist in its parents otherwise it bubbles up events to the parent manager. So if you have a search box and you want your Ad Rotator to know when someone hits search but the search box is a user control or if you want to pass the search input to another control via some event (OnSearch).


Schedule is usually more prohibiting than money, so we pay someone else to figure it out like Telerik 

W3bbo wrote: ...(e.g. WebDAV)... ...why isn't it just FtpRequest?...

WebFTP is trademarked; http://webftp.cygnuspub.com/license.htm

 and the

Finnish
IT center for science has a database called
   PreQuest

http://www.csc.fi/english/research/software/prequest

Any more questions?