On 06/10/2014 04:04 PM, Reinier Olislagers wrote:
I thought that was the entire point of your code but I may be mistaken?
Yep (once the code in fact works to my satisfaction).
n fact I currently don't have any project in favor of myself, hence -
besides curiosity - my intention is to enhance
On 10/06/2014 15:03, Michael Schnell wrote:
> On 06/10/2014 01:59 PM, Reinier Olislagers wrote:
>> @Michael Schnell: how is the non GUI event stuff coming along?
>
> As written in the other thread, it does work nicely using the
> current (updated) version of EpikTimer (or alternatively using some
On 06/10/2014 01:59 PM, Reinier Olislagers wrote:
how is the non GUI event stuff coming along
BTW: obviously you did notice that the issues are connected: doing a
"stateful server" in a CGI does need the non GUI event stuff.
I did not research how "CustomDrawn" handles events (originated by th
On 06/10/2014 01:59 PM, Reinier Olislagers wrote:
Didn't this exact same discussion not happen some months back?
Yep. here or somewhere else.
IMHO, as the computing world gets more "client/server" centric, the Web
GUI issue gets increasingly interesting when deciding which programming
environ
On 10/06/2014 13:45, Michael Schnell wrote:
> On 06/10/2014 01:19 PM, Michael Van Canneyt wrote:
>>
>> Because this nice stuff does not translate to web.
>
> Of course not 1:1.
>
> And of course not easy to do (the "ExtPascal" project did try this some
> years ago and AFAIK it is on a halt since
On 06/10/2014 01:19 PM, Michael Van Canneyt wrote:
Because this nice stuff does not translate to web.
Of course not 1:1.
And of course not easy to do (the "ExtPascal" project did try this some
years ago and AFAIK it is on a halt since long)
But my QNAP NAS at home features a Web GUI that h
On Tue, 10 Jun 2014, Michael Schnell wrote:
On 06/10/2014 01:02 PM, Michael Van Canneyt wrote:
This is simply not correct.
Sorry. I don't understand.
I feel that an LCL based GUI is "stateful serve" and hence what you say is
suicidal.
I didn't speak about LCL based. I do speak about d
On 06/10/2014 01:02 PM, Michael Van Canneyt wrote:
This is simply not correct.
Sorry. I don't understand.
I feel that an LCL based GUI is "stateful serve" and hence what you say
is suicidal.
See the non-lcl widget support.
Of course it is possible to do widgets without support of the lCL
On Tue, 10 Jun 2014, Michael Schnell wrote:
On 06/10/2014 11:47 AM, Michael Van Canneyt wrote:
IMO a web-gui that needs a stateful server part is suicide (it doesn't
scale at all),
and therefor I consider that a bad example.
I see your point, but this would prevent any attempt to do a
On 06/10/2014 11:47 AM, Michael Van Canneyt wrote:
IMO a web-gui that needs a stateful server part is suicide (it doesn't
scale at all),
and therefor I consider that a bad example.
I see your point, but this would prevent any attempt to do a
web-interface that can be designed via the Laza
On Tue, 10 Jun 2014, Michael Schnell wrote:
On 06/10/2014 10:38 AM, Michael Van Canneyt wrote:
Websockets are good when the server needs to push similar data at high
speed, no more, no less.
Hmm.
I understand that websocket is a TCP/IP protocol that (after being opened due
to commands c
On 06/10/2014 10:38 AM, Michael Van Canneyt wrote:
Websockets are good when the server needs to push similar data at high
speed, no more, no less.
Hmm.
I understand that websocket is a TCP/IP protocol that (after being
opened due to commands communicated via HTTP) stays open and hence
prov
On Tue, 10 Jun 2014, Michael Schnell wrote:
On 06/10/2014 10:22 AM, Michael Van Canneyt wrote:
The purpose of a websocket is entirely different, these are not
interchangeable technologies.
A websocket is not even the HTTP protocol.
I do know this. I was told that websocket is a kind of suc
On 06/10/2014 10:22 AM, Michael Van Canneyt wrote:
The purpose of a websocket is entirely different, these are not
interchangeable technologies.
A websocket is not even the HTTP protocol.
I do know this. I was told that websocket is a kind of successor
technology for the replacement of not ve
On Tue, 10 Jun 2014, Michael Schnell wrote:
On 06/06/2014 07:48 PM, silvioprog wrote:
The http server does not support keeping the connection open.
Michael.
:-(
I recently learned (but did not do any testing yet) that "Websocket" is the
current way to go instead of keepi
On 06/06/2014 07:48 PM, silvioprog wrote:
The http server does not support keeping the connection open.
Michael.
:-(
I recently learned (but did not do any testing yet) that "Websocket" is
the current way to go instead of keeping an http socket open.
If course the browser, the server,
2014-06-07 4:54 GMT-03:00 Michael Van Canneyt :
>
> On Fri, 6 Jun 2014, silvioprog wrote:
>
>> 2014-06-06 13:17 GMT-03:00 Michael Van Canneyt :
>> On Fri, 6 Jun 2014, silvioprog wrote:
>> Hello,
>> I'm testing the CustHttpApp unit, and I found one error. See
>> the htt
On Fri, 6 Jun 2014, silvioprog wrote:
2014-06-06 13:17 GMT-03:00 Michael Van Canneyt :
On Fri, 6 Jun 2014, silvioprog wrote:
Hello,
I'm testing the CustHttpApp unit, and I found one error. See the
httperf logs below:
The http server does not support keeping the
2014-06-06 13:17 GMT-03:00 Michael Van Canneyt :
>
> On Fri, 6 Jun 2014, silvioprog wrote:
>
>> Hello,
>> I'm testing the CustHttpApp unit, and I found one error. See the httperf
>> logs below:
>>
>
> The http server does not support keeping the connection open.
>
> Michael.
:-(
--
Silvio Cléc
On Fri, 6 Jun 2014, silvioprog wrote:
Hello,
I'm testing the CustHttpApp unit, and I found one error. See the httperf logs
below:
The http server does not support keeping the connection open.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.
Hello,
I'm testing the CustHttpApp unit, and I found one error. See the httperf
logs below:
CGI (tested with FastCGI and it worked succefuly too):
---
httperf --client=0/1 --server=127.0.0.1 --port=80
--uri=/cgi-bin/project1.cgi --rate=100 --send-buffer=4096
--recv-buffer=4096 --num-conns=1 -
21 matches
Mail list logo
