title : indy - what's the advantage of indy?

      hi~

      i used common socket component that Delphi 5 offers on my program.
      but i'm going to change it to indy component.

      but there are some differences in indy.
      so i would like to know what the advantage of indy is.... mainly in
socket
      comp...

      there are many versions and many differences between them...
      is latest version is the best thing?

      And is there anything to reference example for each indy component?

      thanks for your reading...

      have a good day~~

Before you make up your mind about
the Indy components, do yourself a
favor and take a look at the

ICS - Internet Component Suite
 at
http://www.rtfm.be/fpiette/indexuk.htm

Freeware but VERY good code.
They work like a charm.

Otto Porter

junwon,Seo <linux...@chollian.net> schreef in berichtnieuws
93dvnl$5r...@news1.kornet.net...

Note that Indy is still BETA. I'm sure the development team will have things
sorted out in due time, but right now, it still seems to be Bug City, with
new releases almost every week.

The standard socket components that come with Delphi are known to be stable,
robust and reliable.

Another point is that Delphi sockets are non-blocking, event-driven.
For reasons unknown to me, Indy uses blocking sockets which, IMVHO, are a
more cumbersome to work with.

--
Regards,

Dirk Claessens
---------------------------------------------------------
http://www.claessens16.yucom.be
Attention: All spamshields raised; E-mails will bounce!
---------------------------------------------------------

I would have to say you aren't looking at the right set of components, you
must be looking at some other webpage.

Every once in a while (from 8b10 to 8b12, and 8b8 to 8b9) they hit a pocket
of bugs. On the other hand, an excerpt from their website (found at
http://www.nevrona.com/Indy): (No Clipping)

<<Begin Snippet>>

December 22, 2000 - Indy 8.0 beta 10 is now available. Get it NOW.

 November 22, 2000 - Indy has been nominated for this year's Delphi
Informant Readers Choice Award. Please cast your vote!

November 22, 2000 - Show you are proud of using Indy.  If you have a product
that uses Indy, you may have it listed at our web-site.

November 16, 2000 - Indy 8.009b is now available including an installation
program and a source-code distribution.  This version fixes several bugs
with Indy 8.008b.   Download

<<End Snippet>>

You're telling me a month between Beta versions is a bad thing? Considering
the fact that the only reason they put out 8b10 was because of a bug
affecting a few servers (a ReadLn bug), I think that's not so bad.

I sure hope you aren't talking about the NetMasters components. ;)

I have a project which right now is under wraps, which uses the Indy
components. I'll just say that the test webserver we built (which has about
98% of the features of Apache for Windows) is, on the whole 172,000% better
(not an arbitrary number. Apache crashes, with no configuration aside from
default, and only people hitting the site of static HTML, an average of 4
times per day. Our webserver has been running for 43 days straight, since we
decided that Apache for Win was a pile of cr*p)

And that is using a "buggy" version of the components, version 8b7.

I would have to disagree with you. I feel blocking sockets are more
reliable, due to the fact that they allow more sequential programming.

Using TServerSocket opens up the possibility of 2 events being fired at the
same time. I once coded a BackEnd server for my company for database
maintenance and logging using the TServerSocket. I have to say that it was
the worst Idea I ever had using those components. It ended up happening that
while a read event got fired, I began writing to the other end, and, while
that was happening, another read event fired, hence writing more data. In
other words, both the Client and Server got overloaded. Result = BSOD!

I switched over to winshoes and, despite the few bugs, the code was easy to
read, fix, and maintain, and I coded the entire project in about 1/4th of
the time (Writing from scratch, almost no duplicated code).

What I would assert, is that if you use the Indy components, be sure to
learn the details of Blocking-ness (See Luke's Dictionary, page 90,481).
Otherwise, some bad stuff can crop up the same was as using
TServerSocket/TClientSocket.

-Luke Croteau

Before I tell you the advantages, let me ask, what is the purpose of the
program? If it is working exactly fine the way it is, I would recommend
against changing that particular program. If there are errors, have you
examined how those errors are getting caused?

It all depends on what you are trying to do. If you are coding High-Traffic
business applications, I would say you are better off using Indy.
If you need an easily maintainable, easily fixable code solution, use Indy.
If you don't need to port your programs over to linux (when Kylix comes
out), use the Socket components.

One of the chief advantages to Indy are the technical help (whenever you ask
a question on the Borland newsgroups, and sometimes when I'm watching here,
you get helped), Maintainability (having the code updated regularly, and
having it on your computer is always a plus), and Portability (Kylix will
ship with Indy 8).

I believe speed is also a factor but my tests are highly inconclusive.

The big problem with using them is they are blocking. That means, while your
App is running, if you are doing lengthy read/writes, your program appears
to have crashed. Indy has a solution for this problem which works a good
deal of the time, but is not infallible.

The latest version is always the best thing. ;)

Most of the components have demos included.

-Luke Croteau

Luke Croteau <l...@dmisoft.com> schreef in berichtnieuws
t5nim6d4a7k...@corp.supernews.com...
[snip]

It depends. I'm a corporate developer, and am supposed to design & write
software that works reliably on a 24/7/365 basis. Right now, I wouldn't even
_consider_ to use Indy, because it is still buggy. I prefer to track down my
own bugs. But, as I said in my posting
/quote
I'm sure the development team will have things
sorted out in due time
/end quote

<gg> We all know the NM components are {*word*99}. I was specifically referring to
Borland's TClient/TServerSocket.

[snip]

I agree that the code might be more "compact", and easier to follow.
With event-driven sockets, you often need to store and maintain context info
between events. As to the reliability, I'm not so sure; I guess this solely
depends on the guy who wrote the app... ( for _both_ blocking and
non-blocking sockets ! )

WIN32 is event-driven from bottom to top, whether we like that or not.
Blocking sockets may work fine in a service, because there you simply don't
_care_ about blocking. But if you write apps with a user interface, you
_have_ to care, because user's don't like to stare at an hourglass cursor.
So you have to do something ( Yes, I've heard all about threads, and no,I'm
not afraid of using threads )

TClient/TServerSocket on the other hand, can be used right out of the box in
all situations.

The real reason for using blocking sockets is simple: Delphi 6/Kylix/Linux;
one code base for both. Linux, I guess, is not so deeply event-based...
( Note carefully that I am _not_ in love with MS <g> )

Huh? I've looked up Einstein again on this topic. He says this is
impossible. You can have A, then B, or B then A, but not both.

[bad experience snipped]

Luke : I am not _against_ Indy, keep up the good work, but as it is now,
Indy is not of what I would call "industrial strength".
But it may be on it's way to become so.

Regards - Dirk