Need C# programmers with socket / TCP interest

[Chad Z. Hower aka Kudzu]

A few of you may recognize me from the recent posts I have made about Indy
<http://www.indyproject.org/indy.html>

Those of you coming to .net from the Delphi world know truly how unique and
"huge" Indy is both as a project, in support, development, and use. But
Indy is new to the .net world.

Indy is a HUGE library implementing over 120 internet protocols and
standards and comes with complete source. Its an open source project, but
not your typical abandonware type. It has a development team of
approximately 40 people who are very active, a dedicated documentation
team, a dedicated demo team, a support team, commercial support options,
and even a book.

Its hard to simply take someones word for this - especially when the word
is from someone who is not well known in the .net world (yet! ).
<http://www.hower.org/Chad/Bio.html>
I currently speak at 6-8 conferences around the world each year as well as
regularly write for Delphi magazines.

But Indy is huge - and even with System.Net.Sockets Indy still has a LOT to
offer. Its like comparing a kitchen knife with Swiss Army's top model
knife.
For some basics you can see:
<http://www.atozed.com/indy/Texts/WhyIndy.iwp>

The team obviously is heavily Delphi based. Many of us are doing C# work as
well because Delphi 8 just arrived and many of us needed .net earlier. And
many of us still cross over back and forth between VS and Delphi.

What we need is some VS users - in this case C# users to join a new team we
are forming. We have not named this team yet, but this team would help us
move foward into the VS / .net (other IDEs) world. Roles will be mixed -
support, input, direction, docs, writing demos, and more. Dont worry - you
dont have to do it all. Thats what a team is about - but everyone can
contribute what they are able too.

Not a guru? It doesnt matter. While we welcome and would love to have some
MVPs and MSCE's on board, we are looking for average Joe's, corporate
developers, students, hobbyists and even the newbie!

Rewards? Well Indy is free. But its a very rewarding experience, as well as
a chance to learn, meet new people, experience new code, and be part of a
team. Best of all to forward a very cool and already successful open source
project!

Previously a Delphi or a current cross over user? If so - you can reply and
lend some credibility to my message for those who have no clue who I am. In
the Delphi world I am fairly well known - but I am a newcomer and do not
have much name recogntion here, and neither does Indy yet.



--
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

 

[Lawrence Oluyede]

What we need is some VS users - in this case C# users to join a new team we
are forming. We have not named this team yet, but this team would help us
move foward into the VS / .net (other IDEs) world. Roles will be mixed -
support, input, direction, docs, writing demos, and more. Dont worry - you
dont have to do it all. Thats what a team is about - but everyone can
contribute what they are able too.

What will this team exactly do?

 

[Chad Z. Hower aka Kudzu]

I forgot to add:

1) Please redistribute this announcement on other forums, to .net website
webmasters, mailing lists and soon of your choices. Please include this
addendum as well.

2) If you are interested, you can use this form to contact me as I am the
chairman of Mercury Team which is the administrative team for Indy.
<http://www.hower.org/kudzu/Mail.html>



--
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]

What will this team exactly do?

It will evolve. Normally what happens is we assign people to an existing
team. But with VS developers the situation is a bit different.

Initially we will form the team and add all members of core team. Then we
will decide which new teams to form and move people to those, or even
existing teams where it applies. Developers may be on more than one team.

We need help with docs, demos, spreading the word, and more. Its really an
open role - each developer has specific talents and interests. We try to
match.

The difference in this role from others is that unless you know Delphi, you
wont be working on the core assembly much. But we want to put a "inside" team
in contact directly with the developers on a priority basis so we can promote
demo creation, doc help etc.. I would say that demos and just general
knowledge are the most important right now. The docs are pretty portable, so
its not an urgent need but help is always welcome there too.


--
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]

Previously a Delphi or a current cross over user? If so - you can reply and
lend some credibility to my message for those who have no clue who I am. In
the Delphi world I am fairly well known - but I am a newcomer and do not
have much name recogntion here, and neither does Indy yet.

Yep. I used to lurk in borland.public.delphi.internet.winsock and
regularly saw your name in there.

As for Indy, I've used several of its components before and am
impressed with it. It could indeed come in handy for .NET developers
who want tried and trusted code that implements a particular protocol
(for example, NNTP).

 

[C# Learner]

A few of you may recognize me from the recent posts I have made about Indy
<http://www.indyproject.org/indy.html>

<snip>

I guess there aren't many Delphi people here!

 

[Chad Z. Hower aka Kudzu]

<snip>

I guess there aren't many Delphi people here!

There are a few - but there are a LOT of messages (ie noise), and its only
been a few hours, and its Saturday.

But really most Delphi people are remaining Delphi. And many of those doing
VS.net development do not hang out in the MS groups. They are pretty friendly
in the .net groups, but the old VS areas were very hostile to Delphites and
just "unfriendly" compared to the Borland areas which has stuck in a lot of
Delphites minds. When I told other Delphites people were friendly here and it
was like the VB 3 days (before Delphi existed) they didnt believe me!


--
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]

There are a few - but there are a LOT of messages (ie noise), and its only
been a few hours, and its Saturday.

But really most Delphi people are remaining Delphi.

Since I'm a student and hobbyist programmer, I have the freedom to
more or less choose any language/framework as I please. I recently
decided to try C#/.NET since it appeared to be a combination of a
language with nice sytax, and a powerful library. Not to mention the
fact that, since Microsoft made it, it's likely to be the next big
programming thing.

In any case, I doubt I'll drop Delphi any time soon, as I've been
using it for years, and still like it. I'll probably give Delphi 8 a
try when I get the chance.

And many of those doing
VS.net development do not hang out in the MS groups. They are pretty friendly
in the .net groups, but the old VS areas were very hostile to Delphites and
just "unfriendly" compared to the Borland areas which has stuck in a lot of
Delphites minds. When I told other Delphites people were friendly here and it
was like the VB 3 days (before Delphi existed) they didnt believe me!

I agree. Just like in the Borland groups, the people here are very
friendly and knowledgeable.

 

[Chad Z. Hower aka Kudzu]

more or less choose any language/framework as I please. I recently
decided to try C#/.NET since it appeared to be a combination of a
language with nice sytax, and a powerful library. Not to mention the
fact that, since Microsoft made it, it's likely to be the next big
programming thing.

All good and valid points.

In any case, I doubt I'll drop Delphi any time soon, as I've been
using it for years, and still like it. I'll probably give Delphi 8 a
try when I get the chance.

Its very nice. But you might want to wait for the first service pack. I
suspectd its due soon.

But the IDE is a "1.0" release if you will. The compiler is what really makes
or breaks it - and that is very very well done for .net.



--
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

 

[Jon Skeet [C# MVP]]

A few of you may recognize me from the recent posts I have made about Indy
<http://www.indyproject.org/indy.html>

Those of you coming to .net from the Delphi world know truly how unique and
"huge" Indy is both as a project, in support, development, and use. But
Indy is new to the .net world.

<snip>

I've thought long and hard about this post, and hopefully it won't
cause offence - wherever there are two ways of reading something,
please take the most constructive and least offensive one.

I don't know very much about Indy - all I've done is look at some of
the web pages, download the .NET assembly and attempt (briefly, and
without any documentation) to use the NNTP client library. I have
absolutely no reason to doubt any of the claims made about the
excellence of the library and its importance in the Delphi world.

That said, I have grave reservations about the approach being taken
with regard to bringing it to .NET. Essentially, it's very obviously a
Delphi library in .NET clothing, as it were. There are three main
aspects to this:

1) The naming/organization conventions
2) The lack of XML documentation
3) The extra Borland-specific types (TStrings etc)

All of these make Indy unappealing as a .NET library - there is the
appearance that .NET is a second-class citizen as far as Indy is
concerned. I believe that the above will prevent Indy from being as
widely used and accepted as it might otherwise do - I believe people
will use "odds and sods" libraries for what they need rather than Indy,
if those libraries are written in a much more .NET-centric manner. This
is clearly a bad thing for Indy in terms of popular use (if you
particularly care about such things), reliability (the more people who
use a piece of open source software, the more reliable it's likely to
be) and community (the more users there are, the more they can help
each other).

To go into each of the drawbacks in more detail:

1) Naming Conventions

I'm probably a bit more gung-ho about naming than most people. I will
often think for quite a while just about the name of a class before
starting to code it, and if I later decide it's suboptimal, I will
spend significant effort changing it. (Refactoring capabilities in
Whidbey will help considerably here - naming has a much nicer feeling
in Eclipse, for instance.)

This is because I regard readability as pretty much *the* most
important thing in code. Code which is readable but broken is easily
fixed - code which works but is unreadable is hard to improve, and code
which is broken and unreadable is hard to fix in the first place.

Conventions aid readability, and one of the great things about modern
languages and platforms is that they tend to have a well-defined set of
conventions. Obviously they are only conventions, and no-one is forced
to use them, but life ends up being sweeter if everyone does. I've had
to read through some Java library code which used a mixture of normal
Java conventions and C naming conventions - it's really not pretty.
Things I normally take for granted (such as normal fields beginning
with a lower case letter, types beginning with an upper case letter
etc) are suddenly gone, and I feel at sea.

I have nothing against the Delphi convention in itself - I haven't
looked at it particularly carefully, but obviously various things leap
out at one (as indeed your FAQ points out). The problem isn't in the
convention itself, just that it's not the same as the .NET conventions.
Mixing the .NET conventions with the Java conventions would be just as
bad - it just makes life harder, and the code no longer looks
consistent.

2) XML documentation

I've been using Java for about 9 years, and .NET for about a year and a
half. I've really become used to code being documented in a
standardised way - preferrably every field, method, type, property etc.
The standardisation is important here, because it means that IDEs can
use the information. I can go for hours without consulting Javadoc
directly when coding in Eclipse. VS.NET isn't quite as good in terms of
displaying all the pertinent information, but it's still pretty good.
Using a library without appropriate documentation available in the IDE
feels like bumbling around with a blindfold on. Either I need to keep
swapping between the documentation and the IDE, or I have to do things
by trial and error, neither of which appeal. Even coding by trial and
error is harder than it might be, due to the naming convention
unfamiliar.

In short, I consider comprehensive XML documentation to be pretty much
a must for a .NET library to be taken seriously.

3) Borland-specific types

If I'm learning a new library, I fully expect to have to learn new
types which are directly related to the subject matter of the library.
I don't expect to have to learn a new string library (etc) at the same
time. I also don't want to have the baggage of those extra libraries
hanging around my application. I don't know how much of the 3M of the
Indy assembly is actually Indy as opposed to Borland, but I expect it's
a not inconsiderable amount. The CLR is memory hungry already, without
extra baggage which really belongs to another environment.


In short, while I would like to use code of the quality of Indy from
within .NET, I don't feel comfortable with using it while it's so
obviously not designed for .NET.

What can be done about this?

The obvious potential next step would be to rewrite the whole thing in
C#. (Or perhaps in Delphi, if there is a version of Delphi which
doesn't rely on Borland's own libraries, using the "old" Delphi
conventions etc.) While an obvious suggestion, I have no doubt
whatsoever that it's entirely impractical - that there's an awful lot
of code here, and that maintaining two versions would be very
difficult. I don't know whether the Indy project is a fan of unit
testing - if it is, that would make things much simpler indeed, but
still not *really* easy.

The next suggestion addresses the first two: start writing XML
documentation (which will take a *long* time, I understand) and work
out a way of converting from Delphi conventions to .NET conventions. We
talked in a previous thread about the difficulty of keeping
documentation in code, but I do believe it's vital for libraries (and
for applications, for the sake of the developers themselves).
Application user documentation is unsuitable for the code itself, but
documenting what every field and method does is good for everyone, as
far as I can see. The convention issue is a slightly tougher one,
because it requires something which can manipulate IL to change names
here there and everywhere. along with a rule engine to guide the
conversions (with suitable override capabilities where the engine gets
it wrong). This obvious affects the documentation as well.

I think it really depends on how serious the Indy team is about .NET.
If the idea is to be able to still support people who are/were Delphi
programmers who are already familiar with Indy and wish to use it in
..NET now they're developing there as well, that's fine, and you don't
need to implement any of the above.

If, however, you're seriously presenting Indy as a first class
networking library for .NET, it's currently a "miss" as far as I'm
concerned. If I need a networking library at the moment, I'll firstly
look for ones which are written specifically for .NET, complying with
its conventions and idioms, then look at how long it would take me to
write a library myself which does enough of what I need, and then I'll
look at Indy. There's no doubt that in some cases the result will be to
use Indy - but probably only until another network library comes up
which does that bit that I need in a more .NET-centric way. This is a
real shame, as I'm sure if I were a Delphi developer I'd embrace Indy
wholeheartedly.

All that being said, I certainly wish the Indy team well, whatever
direction they choose to take the project in. If that direction is one
which interests me further (e.g. either of the two work-heavy
suggestions above), I'll be more than happy to help however I can. I'm
sorry if this post has sounded mostly negative - it in not a reflection
of my feelings about the Indy project in general, or the developers.
It's *only* a reflection of how unfortunately far short Indy falls of
being a library I'd consider immediately when thinking about any
networking task. (Even "falling short" is inaccurate - it doesn't fall
short of a target so much as it jumps and hits an entirely different
and irrelevant (to me) target.)

Oh, and congratulations to anyone who managed to read this far. Have a
lollipop.

 

[Chad Z. Hower aka Kudzu]

I've thought long and hard about this post, and hopefully it won't
cause offence - wherever there are two ways of reading something,

Not at all.

1) Naming Conventions

An extra T does not break a library. Removing T's would break the Delphi
base quite badly by breaking ALL user code.

We could do a search and replace on build for VS, but this would make a
real hack of the docs. Sure its possible, but Im just not convinced that
people are goig to say "Damn, its got a T. Cant use it".

I have nothing against the Delphi convention in itself - I haven't
looked at it particularly carefully, but obviously various things leap

Its just like in C++ undef MFC the convention was to prefix classnames with
C. Some C# programmers still do it.

2) XML documentation

We think we have this one solved, but its going to be a few weeks to be
able to output the docs to this format.

3) Borland-specific types

If I'm learning a new library, I fully expect to have to learn new
types which are directly related to the subject matter of the library.
I don't expect to have to learn a new string library (etc) at the same
time. I also don't want to have the baggage of those extra libraries

A) We really only expose two that you will see.

B) Both have direct adaptors that you just "cast" and they are done.
Examples in the article.

We have considered ifdeffing in .net versions, but it makes spaghetti of
the code with IFDEFS. It is possible we could make the build process
somehow parse and modify but that looks like it would require some hefty
parsing.

hanging around my application. I don't know how much of the 3M of the
Indy assembly is actually Indy as opposed to Borland, but I expect it's
a not inconsiderable amount. The CLR is memory hungry already, without
extra baggage which really belongs to another environment.

The Delphi "environment" its not very memory hungry to use. Its just that
we have to staticly link in the RTL parts rigtht now and AFAIK in the .net
version it does not elinate unused code. However probably a good deal of
the 3M is Indy. Indy is HUGE.

The obvious potential next step would be to rewrite the whole thing in
C#. (Or perhaps in Delphi, if there is a version of Delphi which

No way - for several reasons.

1) Creating a fork. Who will maintain it?

2) Who will port it?

3) What about the existing user base? It is HUGE.

doesn't rely on Borland's own libraries, using the "old" Delphi

Fork problems.

conventions etc.) While an obvious suggestion, I have no doubt
whatsoever that it's entirely impractical - that there's an awful lot
of code here, and that maintaining two versions would be very
Exactly.

difficult. I don't know whether the Indy project is a fan of unit
testing - if it is, that would make things much simpler indeed, but
still not *really* easy.

VERY big:
http://www.indyproject.org/bubelen/

The next suggestion addresses the first two: start writing XML
documentation (which will take a *long* time, I understand) and work

Actually not that bad. Its just a matter of getting our existing docs to be
able to output this way.

out a way of converting from Delphi conventions to .NET conventions. We
talked in a previous thread about the difficulty of keeping
documentation in code, but I do believe it's vital for libraries (and
for applications, for the sake of the developers themselves).

Not in code. I stated briefly before:

1) Developers dont update it.

2) It interferes with the code by adding tons of noise.

3) The code editor is a code editor - it makes a horrible word processor
and then you have to manually edit tags and cross link, etc.

4) It pits the docs team against the dev team in the VCS.

If, however, you're seriously presenting Indy as a first class
networking library for .NET, it's currently a "miss" as far as I'm
concerned. If I need a networking library at the moment, I'll firstly

Since XML docs are not an issue anymore, I dont see that an extra T kills a
library.

Nor the convertors as they are just an extra few letters on certain
methods.

Both are possibly resolvable, but take time and Im not sure they are
critical.



--
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]

Two other things I should mention.

1) There are no libraries as extensive as Indy. Most users end up hacking
their own protocols each time. Years ago this was how Delphi was too.

2) Its free.


--
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]

3) The extra Borland-specific types (TStrings etc)

Regarding this point, here is some sample code:

using System;
using System.IO;
using System.Text;
using Indy.Sockets.IdCLRStream;
using Indy.Sockets.IdHTTP;

namespace IntroHTTP
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
ASCIIEncoding LASCII = new ASCIIEncoding();
String LResult;
MemoryStream LStream = new MemoryStream();
TIdHTTP LHTTP = new TIdHTTP();

LHTTP.Get("http://www.atozed.com", new TIdCLRStream(LStream));
LResult = LASCII.GetString(LStream.ToArray());
LStream.Close();

Console.WriteLine(LResult);
Console.WriteLine("Press Enter");
Console.ReadLine();
}
}
}

It looks very .net to me. Considering how much monkeying it takes to get a
string from a stream in .net compared to native Delphi, I really cannot
image that this:

LHTTP.Get("http://www.atozed.com", new TIdCLRStream(LStream));

vs

LHTTP.Get("http://www.atozed.com", LStream);

Would make developers drop a library. Especially after things like:

LResult = LASCII.GetString(LStream.ToArray());

Which are pure ..net.

You can ignre the L,s etc. Thats not Indy, just my convention.

Aside from this the TId is the only "odd" thing. And its certainly not
completley foreign, or for that matter even a technical issue. A "TId" in
no way affects the technical aspects of the library.

So I return the questions.

1) Assume docs are solved.

2) TId - can be solved but Im not sure that it needs to. If you REALLY
think its that big of a issue, we're open to it. I certainly could have my
mind changed to (in time) alter the build process to modify the Indy files
on the fly during the build process for .net.

3) TIdCLRStream and TIdStringArray are the two adaptors you need.
Everything else is pretty much strings, etc... And you can see how easy
they are to use. You dont even need to mess with them. In fact they "Act"
like a cast.

There are no other places you would see "VCLisms" that I can think of.
Delphi is an amazingly flexible language and Borland did an incredible job
of mapping it to .net.

The only reason these two remain are because we have a single source issue.
They could be eliminated with ifdefs, but that creates a BIG maintainance
as well as initial issue as these two types are very very commonly used.

Also keep in mind that this release so far is just a "preview" and or test.
We ARE open to discussion and changes - but we do have an existing HUGE
user base. As for .net - this is exactly why we want to bring some .net
developers in.


--
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

 

[Jon Skeet [C# MVP]]

Not at all.

Goodo

An extra T does not break a library. Removing T's would break the Delphi
base quite badly by breaking ALL user code.

We could do a search and replace on build for VS, but this would make a
real hack of the docs. Sure its possible, but Im just not convinced that
people are goig to say "Damn, its got a T. Cant use it".

It's not just a T though, of course. It's a TId, an Id, an EId, a
TEvent etc. It certainly doesn't *break* a library, but when mixed with
the .NET conventions, it makes for far less readable code, IMO. Don't
forget that you're rather used to the conventions - I'm thinking about
people whose *only* exposure to the Delphi conventions is Indy.

Its just like in C++ undef MFC the convention was to prefix classnames with
C. Some C# programmers still do it.

Not if they're in my team they don't

Mixing conventions is just a really bad idea, IMO - for one thing the
conventions are a subliminal hints about which language you're using,
so you don't get confused in terms of the idioms to use etc.

We think we have this one solved, but its going to be a few weeks to be
able to output the docs to this format.

Excellent. That's a big step forward.

A) We really only expose two that you will see.

Unfortunately the other types are still public. Typing "b" then ctrl-
space in VS.NET is still going to suggest "Borland", and in the classes
where the developer has a "using Borland.Vcl.Classes" directive to make
working with TStrings easier, typing "t" then ctrl-space is going to
suggest loads of extra classes.

B) Both have direct adaptors that you just "cast" and they are done.
Examples in the article.

That's good. I hadn't seen that in the article.

We have considered ifdeffing in .net versions, but it makes spaghetti of
the code with IFDEFS. It is possible we could make the build process
somehow parse and modify but that looks like it would require some hefty
parsing.

Hmm... I'll have a think about any ways round that, after looking at it
a bit further. It might be possible to write a tool which put the cast
into the library (before return or on accepting a parameter) rather
than exposing it.

The Delphi "environment" its not very memory hungry to use. Its just that
we have to staticly link in the RTL parts rigtht now and AFAIK in the .net
version it does not elinate unused code. However probably a good deal of
the 3M is Indy. Indy is HUGE.

I'm sure Indy is big, but IL is generally pretty small For the sake
of interest, I'll look into this and come back with the results.

No way - for several reasons.


VERY big:
http://www.indyproject.org/bubelen/

Cool - not that it helps in this case, but good anyway

Actually not that bad. Its just a matter of getting our existing docs to be
able to output this way.

Good news.

Not in code. I stated briefly before:

1) Developers dont update it.

Then they should be encouraged to, IMO. If a developer doesn't update
the docs, how is anyone else supposed to? Isn't it just as quick to
write a short note in the docs as to what's changed as it is to write
the same note to someone in the docs team so that they can do it at a
later date?

2) It interferes with the code by adding tons of noise.

Code folding takes care of this where it's an issue, I find. Indeed,
unless I'm editing a method, I find it's often a good idea to *only*
have the method comment up rather than the method body. If the method
comment doesn't cover everything you need to know, then the comment
should be fixed.

3) The code editor is a code editor - it makes a horrible word processor
and then you have to manually edit tags and cross link, etc.

I don't find that a problem, myself. I don't tend to use that many
cross-links that aren't automatically generated, admittedly, but I
still don't find it a problem. Type/member/method level docs should
rarely be that lengthy, IMO.

4) It pits the docs team against the dev team in the VCS.

The dev team should *be* the docs team when it comes to documenting
methods etc, IMO. Or at least, they should be the principle docs team,
with there being others putting a bit of spit and polish on if a
developer isn't a particularly good natural language communicator, for
example.

Since XML docs are not an issue anymore, I dont see that an extra T kills a
library.

Nor the convertors as they are just an extra few letters on certain
methods.

Both are possibly resolvable, but take time and Im not sure they are
critical.

As I said before, I'm sure they aren't a problem at all for you, as
you're already familiar with the convention, but I'm speaking for
myself - and I they lead to a significant reduction in readability as
far as I'm concerned.

When the XML documentation is available I'll give it another try, but
with readability being of huge importance to me, the conventions are
the main thing for me. They're also likely to be the first thing to put
off other people who are quickly looking at various libraries - if one
of them looks out of place (as conventions from another environment
do), they're likely to move on without seeing all the good things about
Indy. If you don't mind people like them (or me) bypassing Indy, that's
absolutely fine - but I'd have felt bad about not giving you this
feedback. "Critical" depends on what the goals of Indy are.

If you ever do decide you'd like to seriously consider something to
convert the naming conventions and possibly Delphi type replacement
(without your Delphi code having to change), let me know and I'll look
into it. I've looked into the PE and IL file formats a bit, and
wouldn't mind revisiting that work and trying to write a tool which let
you really manipulate assemblies in the kind of ways I've been talking
about. It wouldn't be a small task, but it would have uses way beyond
Indy.

 

[Chad Z. Hower aka Kudzu]

1) The naming/organization conventions

With C++ in MFC at least classes were C+Classname. C++ does allow managed
code. Assuming that somone has "ported" existing code and its single source -
have they removed all their C's from the code?



--
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

 

[Bas Gooijen]

1) There are no libraries as extensive as Indy. Most users end up hacking

their own protocols each time. Years ago this was how Delphi was too.

2) Its free.

3) It's open source

4) It's very actively maintained and extended

Bas

 

[C# Learner]

2) TId - can be solved but Im not sure that it needs to. If you REALLY
think its that big of a issue, we're open to it. I certainly could have my
mind changed to (in time) alter the build process to modify the Indy files
on the fly during the build process for .net.

To be honest, I agree with Jon on this point. I think it'd look a bit
"out of place" having "TId" prefixes on some class names. I'd imagine
this would be a big turn-off for those who really like good-looking
code.

For example:

public static void Foo()
{
ArrayList list = new ArrayList();
TIdHTTP http = new TIdHTTP();
ASCIIEncoding ascii = new ASCIIEncoding();
//...
}

Compared to:

public static void Foo()
{
ArrayList list = new ArrayList();
HTTPSocket http = new HTTPSocket();
ASCIIEncoding ascii = new ASCIIEncoding();
//...
}

In my eyes, the second snippet of code looks nicer.

But then, I'm not the one who would have to change the build process
to accomplish this!

Just my 0.02.

Cheers

 

[C# Learner]

Its very nice. But you might want to wait for the first service pack. I
suspectd its due soon.

But the IDE is a "1.0" release if you will. The compiler is what really makes
or breaks it - and that is very very well done for .net.

Thanks for the heads up.

 

[Bas Gooijen]

3) TIdCLRStream and TIdStringArray are the two adaptors you need.

Everything else is pretty much strings, etc... And you can see how easy
they are to use. You dont even need to mess with them. In fact they "Act"
like a cast.

maybe the functions could be overloaded, so they accept the standard .NET
classes
( ifdef-ed for the dotnet build)

Bas

 

[Jon Skeet [C# MVP]]

3) The extra Borland-specific types (TStrings etc)

Regarding this point, here is some sample code:

using System;
using System.IO;
using System.Text;
using Indy.Sockets.IdCLRStream;
using Indy.Sockets.IdHTTP;

namespace IntroHTTP
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
ASCIIEncoding LASCII = new ASCIIEncoding();
String LResult;
MemoryStream LStream = new MemoryStream();
TIdHTTP LHTTP = new TIdHTTP();

LHTTP.Get("http://www.atozed.com", new TIdCLRStream(LStream));
LResult = LASCII.GetString(LStream.ToArray());
LStream.Close();

Console.WriteLine(LResult);
Console.WriteLine("Press Enter");
Console.ReadLine();
}
}
}

It looks very .net to me. Considering how much monkeying it takes to get a
string from a stream in .net compared to native Delphi, I really cannot
image that this:

Well, it doesn't take *quite* that much monkeying. I would use:

string result;
using (MemoryStream ms = new MemoryStream())
{
new TIdHTTP.Get ("http://www.atozed.com", new TIdCLRStream(ms));
result = Encoding.ASCII.GetString(ms.ToArray());
}

for clarity myself.

However, a nicer interface (IMO) would be for LHTTP.Get to take a
TextWriter as a parameter instead, if it's fundamentally going to be
writing character data. Alternatively, I'd have LHTTP.Get *return* a
stream, or TextReader, or string, rather than take one and write into
it. Maybe the "passing in a stream" way of doing things is common in
Delphi - it's not in .NET.

So I return the questions.

1) Assume docs are solved.
Yup.

2) TId - can be solved but Im not sure that it needs to. If you REALLY
think its that big of a issue, we're open to it. I certainly could have my
mind changed to (in time) alter the build process to modify the Indy files
on the fly during the build process for .net.

I think it can be "post build" as it were - it needn't do anything to
source files, certainly.

3) TIdCLRStream and TIdStringArray are the two adaptors you need.
Everything else is pretty much strings, etc... And you can see how easy
they are to use. You dont even need to mess with them. In fact they "Act"
like a cast.

I'm pretty sure I could work out something to get rid of them though,
and even if you don't want to do that, I hope you wouldn't mind me
using Indy in a modified form

There are no other places you would see "VCLisms" that I can think of.
Delphi is an amazingly flexible language and Borland did an incredible job
of mapping it to .net.

The only reason these two remain are because we have a single source issue.
They could be eliminated with ifdefs, but that creates a BIG maintainance
as well as initial issue as these two types are very very commonly used.

Also keep in mind that this release so far is just a "preview" and or test.
We ARE open to discussion and changes - but we do have an existing HUGE
user base. As for .net - this is exactly why we want to bring some .net
developers in.

Obviously I don't want to do anything that would adversely affect your
existing user base - I'm just interested in how much effort you're
willing to put into making it *really* inviting for "just .NET" users -
and in my view, the crux of that is the naming convention issue, which
again I think I can solve, albeit with a lot of work, but in a fairly
future-proof way.