[OT] .NET Rant

[Nick Malik]

It is an impression in your mind, but not in the advertising.

Microsoft NEVER said this. You may have interpreted their message in this
way, that's fine, but your misimpression is a far cry from "false
advertising."

Also, when the product managers were going through the list of features to
include in the framework, they hit nearly every need. They nailed most
everything that's in the Java libraries, plus a whole lot more. For
application development, .NET is excellent.

You have to admit that writing a web proxy server is not a TYPICAL thing to
do. It is not something that a long list of people will turn to .NET for.
Most proxy servers are written in C or C++ by skilled programmers who don't
mind a little extra code to tweak out that last little bit of speed.

You are unusual, as are your needs. In your shoes, you can't complain
because the framework doesn't give you a single feature that you perceive as
necessary.

--- Nick

 

[C# Learner]

It is an impression in your mind, but not in the advertising.

Microsoft NEVER said this. You may have interpreted their message in this
way, that's fine, but your misimpression is a far cry from "false
advertising."

Also, when the product managers were going through the list of features to
include in the framework, they hit nearly every need. They nailed most
everything that's in the Java libraries, plus a whole lot more. For
application development, .NET is excellent.

You have to admit that writing a web proxy server is not a TYPICAL thing to
do. It is not something that a long list of people will turn to .NET for.
Most proxy servers are written in C or C++ by skilled programmers who don't
mind a little extra code to tweak out that last little bit of speed.

No, it's not a "typical" thing.

If HttpWebRequest and HttpWebResponse didn't exist, I wouldn't have
said anything. However, since they do exist and they deny this power,
I had a rant.

What would be so bad about something like the following?

HttpWebRequest request = new HttpWebRequest();
request.Parse("GET HTTP/1.1 /\r\n\r\n");

This could be so handy. I see no reason why this doesn't already
exist.

Or perhaps something similar to the following could have been
implemented.

RawHttpWebRequest raw =
new RawHttpWebRequest("GET HTTP/1.1 /\r\n\r\n");
HttpWebRequest request = new HttpWebRequest(raw);

You are unusual, as are your needs.

Was a personal insult required here?

In your shoes, you can't complain
because the framework doesn't give you a single feature that you perceive as
necessary.

In my shoes? Into the killfile you go.

 

[Chad Z. Hower aka Kudzu]

Excellent! I didn't realize Indy's HTTP component had this.

Yep. Nothing really comes close to completeness as Indy does. Indy's been
around for 10 years now - had quite a bit of time to mature.

I'll give it a try now.

Any questions just ask.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Chad Z. Hower aka Kudzu]

I agree on this. While the socket and TCP support may be lacking - in this
area and others, this is a separate issue from the .net framework itself.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[C# Learner]

Yep. Nothing really comes close to completeness as Indy does. Indy's been
around for 10 years now - had quite a bit of time to mature.


Any questions just ask.

So far, I have been asking in the HTTP newsgroup over at
news.atozedsoftware.com and have been getting help from Remy Lebeau
(very helpful), who advised me to use the MappedPortTCP component
instead.

It seems that most of the work is already done for me, with this
component.

Cheers

 

[Chad Z. Hower aka Kudzu]

news.atozedsoftware.com and have been getting help from Remy Lebeau
(very helpful), who advised me to use the MappedPortTCP component
instead.

It seems that most of the work is already done for me, with this
component.

Yes a lot has been done. Indy has a lot of components to choose from.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Abhishek Srivastava]

On the lighter side:

In any programming language (or platform) usually the phrase "i want to
use raw .... " means " I am prepared to do the extra work ..... "

When you use libraries, there is a saying "Library designer giveth...
Library designer taketh" which essentially means tradeoffs.

Most libraries give convience because "raw" plumbing work is hidden from
programmers. Most of the times libraries are designed with some
tradeoffs. They give some convienince based on the task which 95% of
programmers do... if they don't suit you then go the hard way.

The apis you are mentioned would be horrible for my application. I hate
this C kind of raw programming. Because raw processing of HTTP messages
would make code very hard to read or maintain. So in one way I am happy
that such *shoot yourself in the foot* apis are not provided. If I ever
needed such raw processing functionality I would rather go for a 3rd
party library which does what I want rather than do raw code.

BTW, if you don't find one api in one of the classes then you are not in
a position to rant about the framework in total. You may give feedback
or rant about a class!

IMO, few weeks are too less to judge the entire .Net f/w

Happy learning.

regards,
Abhishek.

I've been learning .NET for a couple of weeks now.

I've found that on the surface, .NET looks powerful and very handy.
However, when getting down and dirty with it, I've found that
sometimes it's no longer the beast it first appeared. It then shows
itself to be irrationally impotent in certain aspects.

Here are a couple of examples:

Example 1
---------

An HttpWebRequest instance cannot be given a "raw" HTTP message. I
see absolutely no reason why this is so, since somewhere along the
line of an HttpWebRequest instance sending a HTTP request, a raw HTTP
message will be sent.

Instead, if one has a raw HTTP message in the first place, one must
parse the raw message (whether it be held in string, byte[], etc.)
into an HttpWebRequest instance.

Why should the user of .NET have to do this? This is ridiculous. In
this case extra processing is involved:

1) User code parses raw HTTP message and builds a new HttpWebRequest
instance from it.
2) HttpWebRequest code then does the complete opposite to get a raw
HTTP message.
3) HttpWebRequest then sends raw HTTP message.

Instead, the following should happen:

1) HttpWebRequest has the ability to send a raw HTTP message, given to
it by user.

Example 2
---------

One cannot retrieve the "raw" HTTP message from an HttpWebResponse.
Again, I see no reason why this should be so, since somewhere along
the line of getting an HTTP response a raw HTTP message is received.

Instead, one must do something like the following:

byte[] headerBytes = response.Headers.ToByteArray();

Then one must somehow prepend the string "HTTP 200 OK\r\n" to those
bytes. Next, of course, one must append the response body.

An example of the clumsiness involved:

string statusString = "HTTP/1.1 200 OK\r\n";
byte[] statusBytes = Encoding.ASCII.GetBytes(statusString);
byte[] headerBytes = response.Headers.ToByteArray();
byte[] bodyBytes = ReadFully(response.GetResponseStream());

// ReadFully is implemented as (obtained from Jon Skeet's site):
public static byte[] ReadFully(Stream stream)
{
byte[] buffer = new byte[32768];
using (MemoryStream ms = new MemoryStream())
{
while (true)
{
int read = stream.Read(buffer, 0,
buffer.Length);
if (read <= 0)
return ms.ToArray();
ms.Write(buffer, 0, read);
}
}
}

Here, we have obtained three byte arrays which add up to a full HTTP
message.

Why can't we simply say the following?

byte[] messageBytes = response.GetRawMessage();

That would be so much nicer, and would be easy to implement. Perhaps
even the following might be more logical:

byte[] messageBytes = response.RawMessage;

...depending on whether an HttpResponse stores the raw message using a
byte[] instance.

Further, why should I need to read from one stream, write to another,
and then, finally, convert this stream to a byte array?

That is bound to be rather inefficient, not to mention the fact that
it takes the implementation of a whole new method.