We are having problems with both Indy 9 and Indy 10 and were wondering if
there is an alternative that we might use. The only part of Indy that we
currently use is the TIdHTTP component and specifically the Post() method to
send a request to an HTTP server and receive the resulting response.
Thanks...
Mark
TALWinHttpClient is a is easy to use WinHTTP-based HTTP client component
which allows to post and get any data from the Web via HTTP protocol
Walter
"Mark D. Lincoln" <mdli...@cycleconsulting.com> wrote in message
news:4421...@newsgroups.borland.com...
I'm not exactly sure of all of its capabilities, but it has worked a
treat for me!!!
-Raymond
What about TurboPower's Internet Professional on source forge?
I've used the HTTP component with no problems..
Seconded. I was having a lot of grief with Indy and I switched to
synapse and it's worked a treat.
ICS Of course !!!
I advise you grab the latest ICS v6 Beta.
--
Pierre Y.
levosgien.net - http://cerbermail.com/?7dwZGWwOB0
(Cliquez sur le lien ci-dessus pour me contacter en privé)
Capitaine anglais : "Vous vous battez pour l'argent, nous on se bat
pour l'honneur !"
Robert Surcouf : "Vous avez raison, Monsieur, chacun de nous combat
pour ce qui lui manque."
--
Trevor de Koekkoek
http://www.aspevia.com
Google Sitemap generator: http://www.sitemagellan.com
I've looked at the problem you're having on the other groups. If you're
willing to change to another component set completely, I'm guessing
there isn't a lot of Indy code in your app, or you're willing to foot a
fair migration cost for what seems a solveable problem.
For the former, it would seem trivial to provide some example code,
which apparently you've provided none.
--
Dave Nottage [TeamB]
Have questions?: http://www.catb.org/~esr/faqs/smart-questions.html
Want answers?: http://support.borland.com
http://www.overbyte.be/eng/products/ics.html was good for me
--
Liz the Brit
Delphi things I have released: http://www.xcalibur.co.uk/DelphiThings
We are only using the TIdHTTP component. We use nothing else from Indy. As
I stated in the thread in the winsock group, we are using the Post() method
of the TIdHttp component and nothing else. I have not shown any code
becarse there is really nothing worth showing. Below is what the code looks
like:
self.oIdHttp.Post( sUrl, oRequestData, oResponseData );
There is nothing else to show. As for switching our code, it looks like
Synapse is the winner. We have created a version of our system that uses
Synapse, and so far, the testing is going well. In addition, we have found
the support for this library is far better than the complete lack of support
for Indy. It seems that since Chad Hower moved on to Microsoft, the project
has lost its direction and nobody still working on the project actually
cares about supporting it anymore. My previous posts about issues with Indy
9 and Indy 10 have either gone ignored or the responder has told us we need
to pay for support to get any real help. This is nonsense. In addition,
the Indy team no longer seems to do production releases of the code. Using
the latest development snapshot in a production environment is precarious at
best and irresponsible at worst. Therefore, unless there is a feature that
someone must have that is only in Indy, I would recommend you try Synapse.
The code is well designed, very well documented, and actively supported by
the author and its user community. Go Synapse!!!
Mark
"Dave Nottage [TeamB]" <rot13....@enqfbsg.pbz.nh> wrote in message
news:44306616$1...@newsgroups.borland.com...
Thank you for your suggestions. After taking a look at all of the
alteratives for Indy, we have settled on Synapse. So far, in our testing,
it has performed very well and the support for it by its author and the user
community has been great. Go Synapse!!!
Mark
"Mark D. Lincoln" <mdli...@cycleconsulting.com> wrote in message
news:4421...@newsgroups.borland.com...
I wouldn't count on paid support being much good either. I dumped Intraweb
for the same reason. I believe the two are related.
> the Indy team no longer seems to do production releases of the code.
> Using the latest development snapshot in a production environment is
> precarious at best and irresponsible at worst.
Yes and they always state, "Are you using the latest version?" If you're
not, then you are taking a larger risk by introducing incompatiblities and
more bugs into your software. Been there many times w/Indy & IW.
> someone must have that is only in Indy, I would recommend you try Synapse.
You could also try ICS. I have not used Synapse, but think I will take a
look at it.
> In addition, we have found the support for this library is far better
> than the complete lack of support for Indy. It seems that since Chad
> Hower moved on to Microsoft, the project has lost its direction and
> nobody still working on the project actually cares about supporting
> it anymore.
Other than Chad working for MS, that is complete and absolute nonsense,
and AFAICR, Chad still has an active interest in Indy.
You asked your original question less than 3 weeks ago, and have had
several replies, at least a couple of which asked for example code, to
which you provided none until now. Others asked for other information
which could help isolate the cause, to which you also provided no
answer; even one to indicate whether or not you were able to, or
prepared to provide the information.
I'm using ICS, it's non-blocking and very fast.
And unlike Indy , it works with SSL.
It has it's own support list.
Paul
> And unlike Indy , it works with SSL.
Indy *does* work with SSL. What gave you the impression that it doesn't?
When we were using Indy 9 and found a problem, we were told to try Indy 10.
When we tried Indy 10, it died under normal production workloads making it
unusable. If you look at the Indy HTTP newsgroup, nobody bothered to
respond to my posting. The replies I received in the winsock group did not
get at the root cause of the problem. I recevied some suggestions, however,
most of them were in the form of "I do this and the problem goes away; give
it a try." Well, that's like saying that if your finger hurts, cut you hand
off and the problem will go away. Among these "solutions" were the
following:
1) Create and Free the TIdHTTP for each request;
2) Wrap the call to Post() in a try..except block with a short delay
(Sleep??) before retrying the connection;
3) Try issuing a DisconnectSocket command in the exception handling code;
and,
4) Run the free Ethereal packet sniffer.
While I appreciate these suggestions, I was looking for a reason why an
implemenation that simply calls Post() and works in Indy 9 dies in Indy 10.
Since Indy 10 has an almost completely new structure from Indy 9, comparing
the code from both versions yeilds nothing useful. The value of an "open
source" project is supposed to be all of the people using, debugging,
testing, and sharing the knowledge about the software. This may have been
the case with prior versions of Indy, but it is no longer the case. If you
are not using Indy 10, forget about getting any help from the project
participants. If you are using Indy 10, you have to use a "development
snapshot". Both of these situations are unacceptable especially when
Borland is shipping Indy with its product. Frankly, we have moved on to
using Synapse and find it preferable in all aspects to Indy for our use.
Mark
"Dave Nottage [TeamB]" <rot13....@enqfbsg.pbz.nh> wrote in message
news:44314f0d$1...@newsgroups.borland.com...
> 4) Run the free Ethereal packet sniffer.
This was to determine the cause, not provide a solution...
> While I appreciate these suggestions, I was looking for a reason why
> an implemenation that simply calls Post() and works in Indy 9 dies in
> Indy 10.
..which the above measure may have helped determined why. Since I and
others have applications that work using Post in Indy 10, it would seem
apparent that it is peculiar to your setup. Using diagnostics would
help determine the cause, and in turn if others are affected, would
help them.
> Since Indy 10 has an almost completely new structure from
> Indy 9, comparing the code from both versions yeilds nothing useful.
The usefulness of comparing the code would have no bearing from whether
the structure is different. It would be useful if there was a change
that was leading to the cause.
> The value of an "open source" project is supposed to be all of the
> people using, debugging, testing, and sharing the knowledge about the
> software. This may have been the case with prior versions of Indy,
> but it is no longer the case.
Just because your particular problem is yet to be solved doesn't make
your generalisation valid.
> If you are using Indy 10, you have to use a "development snapshot".
Nonsense: Indy 10 has a release version.
> Both of these situations are unacceptable especially when Borland is
> shipping Indy with its product.
You're only considering the situation to be "unacceptable" because your
problem is yet to be solved.
I switched to ICS 18 months ago and I'm happy I did.
It also works faster and you don't need to put everything in threads to get
you GUI more responsive.
Paul
> I have tested a lot with Indy SSL (http) and frequently had troubles
> with it.
If you have something to substantiate the problem, I'd be interested.
What's the Synapse web site ?
TIA
Best Regards
Jed
"Mark D. Lincoln" <mdli...@cycleconsulting.com> escreveu na mensagem
news:4431...@newsgroups.borland.com...
--
With best regards, Mike Shkolnik
E-mail: mshk...@scalabium.com
WEB: http://www.scalabium.com
If its commercial thats okay too, but I would not like to spend a fortune
on it either.
I know that many of the things I mentioned can be done with Indy, but I am
looking to save development time and want the features I mentioned to be
polished and able to handle all kinds of scenarios.
Does Clever components provide these features?
--- posted by geoForum on http://delphi.newswhat.com
You can check the details yourself, but I've used various of the
components and they all work fine without too much hassle or thought
needed. I never found the same with Indy.
/Matthew Jones/
Matt, have you used ICS? It looks to be promising for the features I am
looking for. I think it does the proxy support also.
The one that looks really good is IPWorks. It is non-blocking like ICS
also and allows you to set timeouts. The HTTP component looks really
polished, progress bar, proxy, error message handling. Problem is it is
$299. Since I am only going to use the HTTP component and RSS, it seems
like a high price to pay.
Very interesting discussion. I am also searching for alternatives to Indy. I
have experimented a variety of problems with their FTP components the answer
to which is "install the latest develoment snapshot" whih of course will
definitly broke something else <VBG>. I used indy because it came installed
with Delphi when we began with our product some years ago, but we are
willing to pay good money for a good suit which have
* good support
* good documentation
* SSL support
* Is more or less stable
and the most important, that doesn't broke the architecture of their
components from release to release.
Clever vs IPWorks. That's the question. Pros and cons?
/Matthew Jones/
synapse -> www.ararat.cz/synapse. Synapse is very straight,
easy to use and will do in most circumstances - it is "just" a
library but that is enough.
Another alternative I use is DXSock, thats something very
professional.
Both are alternatives as long as Indy is the problem and the
problem does not sit in front of the computer.
Mike
I am new to threads so any product that comes with excellent working
examples of how to accomplish this would be great.
Sounds like ICS is not easy to use with threads. Has anyone done multiple
HTTP downloads with ICS with a responsive GUI?
The only issue I see with the synapse lib is that the documentation on the
Wiki was not that great for HTTP and did not show any full code examples
(i.e. demo programs).
It seems IPWorks has tons of demo programs. Not sure about Clever since I
have not looked at them yet.
Does IPWorks or Clever have any multi-threaded HTTP or FTP demo apps to
work with?
T> * good support
T> * good documentation
T> * SSL support
T> * Is more or less stable
T> and the most important, that doesn't broke the architecture of their
T> components from release to release.
You can check FTPSBlackbox ( http://www.eldos.com/sbb/delphi-ftps.php ), it
has all of the above and comes with source.
With best regards,
Eugene Mayevski
I was very impressed with this demo. It showed the progess bar and
download bytes being updated for each download, while the GUI remained
fully responsive. There was some slight flickering with the progress bar
repaint, but this was not that bad. I had 5 downloads going at one time
each with 4 threads allocated for each download. One did fail the first
time, but could easily be resumed and it picked up downloading where it
left off. I fixed this issue by extending the timeouts so that it did not
fail in my second round of tests.
You can set all kinds of properties on each download, like:
- timeout and retry
- number of threads (so a single download could be done in multiple
threads, like p2p clients do)
- and many more
There support guarantee is also very impressive. They claim that if an
email is not answered in 3 days, that they will effectively refund the
amount you paid for that product. Can anyone confirm this claim, that is
they answer emails this quickly or stand by that refund clause?
/Matthew Jones/
They have replied to several emails with questions about their products,
all within 2 days.