Re: SMTP and SSL

Is it everybody or just me who gets really miffed when I upgrade only to
find that a complete rework is required to use the new version.  When
Microsoft does this everybody screams and complains.

I installed the version 9 if Indy to get the fixes for problems with email
functions only to find that they completely re-structured the components.  I
think re-structuring is fine - leave the old component and make a new one.
That way people who CHOOSE to use the new one can and old code doesn't have
to be rewritten the day you install the upgrade.  They did this for the
upgrade from version 7 to 8 also.

Now I have to make replacements for routines that took me days to figure out
the first time!

Sorry - I have to complain, otherwise people don't know what they are doing
is wrong.  If I did this with my clients, I wouldn't need Indy anymore - I'd
be on welfare.

oh? did you pay for Indy?

Grahame

news:3ec570ae@newsgroups.borland.com...

Complete rework? Ooh, let me guess how you've written your code ;)
Because Indy is going to keep evolving, try creating some code libraries and
classes with standard functions for acessing emails, sockets, etc whatever
you're using Indy for to prevent future headaches. Have the classes create
Indy components dynamically.
Then, when the next release arrives, you can just change your classes as
necessary and recompile your app....

"Slider" <k...@hotmail.com> wrote in news:3ec570ae@newsgroups.borland.com:

For most users its just simple changes. Certainly not a rewrite.

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

   Want more Indy stuff? Try the Atozed Indy Portal at
        http://www.atozedsoftware.com/
    * More Free Demos
    * Free Articles
    * Extra Support

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

So why didn't you answer this from 5/12?

Hi:

   BCB5

Errors from changing 8.22 -> 9.xx. Just reopened bcb app which
compiled fine under 8.22, recompiled and now this:

[C++ Error] dmIBAdmin.cpp(279): E2193 Too few parameters in call to
'_fastcall TIdTCPClient::Connect(const int)'
[C++ Error] dmIBAdmin.cpp(283): E2193 Too few parameters in call to
'_fastcall TIdTCPConnection::ReadLn(AnsiString,const int,int)'
[C++ Error] dmIBAdmin.cpp(288): E2193 Too few parameters in call to
'_fastcall TIdTCPConnection::ReadLn(AnsiString,const int,int)'

   Under 8.22 this compiled fine with Client->Connect() and
   TCPClient->ReadLn("", 5000);

Why? Cant find any documentation on this and in Delphi (my apps your
demos) still works with Connect; without parameters.

Don't understand what is going on here.

Thanks.   Best regards

What has that got to do with it?

well, the original claim was:

 > Sorry - I have to complain, otherwise people
 >don't know what they are doing is wrong.  If
 >I did this with my clients, I wouldn't need
 >Indy anymore - I'd be on welfare.

and this is pretty much true, and indeed a
number of libraries that I paid for would
do well to heed the advice

However, you don't "buy" Indy. Those of
us who write for Indy - and most of
all Kudzu - we do it because we want to.
That was the basis for my comment.

my other comment is that maintaining
backwards compatibility corrupts your
code, either you don't fix things that
you should, or you maintain multiple
incompatible ways of doing things

You should expect to have issues when
you have a major upgrade - just like
you expect to have major improvements

The primary issues in software development
is change. it happens, continually. Deal
with it (adapted from Bertrand Meyer)

Grahame

liberte <B24liberat...@netscape.com> wrote in news:3EC623B1.7010901
@netscape.com:

Same reason I dont answer a LOT of posts in this forum. I have a day job just
like the everyone else in here. I simply dont have the time to answer every
post.

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

   Need extra help with an Indy problem?

   http://www.atozedsoftware.com/indy/experts/support.html

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

Excellent point. Sorry.

Chad Z. Hower aka Kudzu wrote:

It would be nice if some document explained the changes.

My post above 8.3->9.x ius an example. App was working fine.
When I opened in IDE after installing 9.x things were screwed up. I
could not find any listing of changes effecting this so I kept trying
to figure out what was wrong. Finally I just changed my code so it
worked. I don't like doing things like that without understanding waht
was changed.

Software Development is change - great.  If you want to create a new
version, by all means, go ahead.  Make a new version and leave the old one
alone.  It's open source, if someone else wants to maintain it, they could.

I didn't pay for it - right.  So, because it's open source, no one should be
responsible to the users?!  That is not a very professional point of view.
When I develop anything, I do so with the sole purpose of satisfying the
users regardless of the sale price of the final product.  If I do a job, I
do it right - or try to.

The mail components in Indy seem to be taking a major hit on every version,
the reason for which only the Indy people can know.  I was thinking the Indy
staff wanted people to use Indy and would want input about this type of
thing.  Forcing user's to re-write their code everytime someone gets a
better idea is not good public relations and it is not "right".

Having said all this stuff, don't get me wrong - Indy components have saved
me a snoot-full of time over the last few years and I am gratefull for their
availability.  It is possible, in this case, to make everybody happy.
Change your code every version if you wish, but change the names also to
leave the compatibility intact. Superceeded function could be identified as
such and new development could start with the new version while old
applications continue to run happily also.  Could it be this easy?

It's just my point of view...

Karl

news:nslhp-eca.ln1@melblink.kestral.com.au...

no, of course, and we try hard - very hard.
how many hours a week is reasonable?

the problem is that "the user" is actually "the users" and they all want
something different. My primary focus is IndySoap, and when I'm working
on that, I have to make value decisions about backwards compatibility.
I've tried to document what commitments we make about backwards
compatibility but then you find that you made a mistake....

Some things you can leave in place. But how do you handle the
requirement to add a parameter to an event? Would you have 2
events? OnConnect, OnConnect1, OnConnect2 - that'd generate
complaints from users.

How about restructuring an object so that a procedure call no
longer makes sense? Would you not perform the restructure? What
if you needed it to fix a bug that was caused by the current
structure? Most of the things I fix fall into this category.

perhaps they weren't very well structured in the first place.
I don't use or work on the email components

as I said, I don't think that we do it just because we get a better
idea. Usually changes are made in response to a bug. Sometimes
pretty significant ones.

I've always preferred to simply drop them so that the compiler
can help me find my uses of them. To each his own. But as I said,
generally they are dropped because not only are they superceded,
but the design has changed and they are unusable. In these days
of default parameters and overloading, it's generally not
required to drop them for simple changes

Grahame

I would rather pay for software at any point in time than to get this type
of feedback any day... and yes I did, having looked at Indy and the changes
I can only believe that the design was not optimal when going to 8, then 9
and now I hear (no first hand experience) 10 does have some major changes.
I am hearing some 'noise' regarding 10 being a complete rewrite but then
again 9 was as well.  Will -11- be another rewrite?

My 2c why I am paying for commercial software rather.

Or use ICS which is freeware and has a single version for _ALL_ Delphi
versions and editions. One of the major ICS design rules is: "Do not break
existing code".

--
Contribute to the SSL Effort. Visit
http://overbyte.delphicenter.com/eng/ssl.html
--
francois.pie...@overbyte.be
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be

Yes, I have looked at your ICS for the some time now and do like the
implementation.  I have downloaded the latest Beta (HTML SMTP implementation
made me sit up just for a review) and some stuff I have done a few years ago
still compile without a hiccup.  Great work.  I use for performance and
DXSock and have been revisiting ICS due to the problems I have currently
with Indy and some other 'supported' software.

news:3ec8d024$1@newsgroups.borland.com...