Hi !
I wrote a new demo showing how to use ICS HTTP client component to access a
REST API (Google Web Search) with JSON.
To parse JSON, I used "SuperObject" which is freeware and very nice.
The demo is named OverbyteIcsRestJasonClientDemo.proj and is available from
the SVN repository at
http
Well, proxies may also break the connections.
Never had problems with that, but new requests are delayed somehow.
Paul
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overby
I don't agree with you. HTTP protocol has all support for real keep alive
connections. request can even be sent before the previous answer has been
received.
BUT most commercial webserver do break the connection very quickly.
Probably to be able to support a large number of clients. If you wri
I don't agree with you. HTTP protocol has all support for real keep alive
connections. request can even be sent before the previous answer has been
received.
BUT most commercial webserver do break the connection very quickly.
Probably to be able to support a large number of clients. If you w
Yes, using HTTP/1.1 you have perstant connexions. See Keep-Alive in the
source code.
That's what I'm using, but it's not the same.
When I post a stream (10k as test) to the server which then sends it to
the other computer, it's about 90 times faster then sending 1000
"10byte"-strings.
of couse
Arno Garrels wrote:
> IMHO it's not very easy to keep backwards compatibility.
Maybe, but the question is what specifically should be done to make ICS support
IPv6. On the component level all IP's are operated as strings - no problem
here. Maybe you'll just need to implement a pair of new functi
Yes, using HTTP/1.1 you have perstant connexions. See Keep-Alive in the
source code.
That's what I'm using, but it's not the same.
When I post a stream (10k as test) to the server which then sends it to the
other computer, it's about 90 times faster then sending 1000
"10byte"-strings.
of couse
Just curious, why? AFAIK Ip6 is not compatible to Ip4, so why not
implement a new branch? Or is the idea that one component should be able
to handle all?
Yes, of course.
I think so--another branch will cause a lot of rework for future updates,
wouldn't it?
Indeed. And some maintenance heada
I'm testing an application that has to control a remote machine.
The communication goes through an intermediate http server that connects 2
http clients.
A<-->Server<-->B<->machine
computer A controls computer B wich controls the machine.
When computer B is located in the US, some message aren't
I'm testing an application that has to control a remote machine.
The communication goes through an intermediate http server that connects 2
http clients.
A<-->Server<-->B<->machine
computer A controls computer B wich controls the machine.
When computer B is located in the US, some message aren't
Just curious, why? AFAIK Ip6 is not compatible to Ip4, so why not
implement
a new branch? Or is the idea that one component should be able to handle
all?
albert
I think so--another branch will cause a lot of rework for future updates,
wouldn't it?
You can't make a version for IPv6 only.
I
On Thu, Jan 21, 2010 at 9:55 AM, A Drent wrote:
>
>
> IMHO it's not very easy to keep backwards compatibility.
>>>
>>
>> And this is very important.
>>
>> --
>>
>
> Just curious, why? AFAIK Ip6 is not compatible to Ip4, so why not implement
> a new branch? Or is the idea that one component shoul
IMHO it's not very easy to keep backwards compatibility.
And this is very important.
--
Just curious, why? AFAIK Ip6 is not compatible to Ip4, so why not implement
a new branch? Or is the idea that one component should be able to handle
all?
albert
--
To unsubscribe or change your s
13 matches
Mail list logo
