🚀 go-pugleaf

Thanks very much Remy for your patience (forbearance)
in addressing these concerns.

Your comments were very helpful.

W.r.t Indy10, I really want to give
it a go - just time, And I know that
there will be a bit of a learning curve
for 'me' and moving to a new platform like
this is tricky for me right now. Frankly
I need to hire a tester - Stability is
important and also understanding any quirky
behavior or implementation details
that comes with the package.

And frankly I will be rewriting my application
for 'enterprise' class load and performance.
When that time comes, Indy10 will surely be a
must.

Remy Lebeau (TeamB) wrote:
> "Colin B Maharaj" <noreply@myhost.com> wrote in message 
> news:47f3feb1$1@newsgroups.borland.com...
> 
>> Note: I did not use the HTTP Server component that came with Indy9.
> 
> Why not?
> 
>> Then, in the last few months I have been able to add HTTP Deflate
>> using the ZLIB Library
> 
> Indy 10 has native support for GZip and Deflate.
> 
>> If I move to Indy10 and the HTTP Server lock, stock and barrel,
>> will I be getting SSL, Deflate and If-None-Match/304 support in
>> the server
> 
> If-None-Match, no.  The others, yes.
> 
>> I saw a brief description of Indy10 support for 'A' as in WSA
>> Asynchronous support
> 
> Indy 10 does not have any WSA asynchronous support in it.
> 
>> claiming to be better supported for many thousands of connections.
> 
> What you are referring to is separate add-on framework (the SuperCore 
> package) that was never finished.  It is very outdated now as it has not 
> been worked on for a long time.
> 
>> But I remember years ago I saw (heard) (cannot remember) that
>> Indy is based on blocking server technology for it implementation
> 
> Yes.  Indy has always used blocking sockets.
> 
>> What's the story with this, should I go with indy10 new super core 
>> structure or stick with the blocking model.
> 
> Since SuperCore does not work, you have to stay with the blocking model.
> 
> 
> Gambit 
> 
>