Re: [fpc-pascal] CustHttpApp and HP httperf tool
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, and any proxy in between needs to support this but I was told that his is supposed to usually to be in place. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler error passing a Property as a parameter
On 06/08/2014 09:50 PM, Graeme Geldenhuys wrote: You can't pass them directly as a var parameter, I feel that generally passing a property as a var parameter is not possible, It could be possible for built-in functions (such as inc() ) or for properties that don't have a set or get function. Of course the compiler could detect these special cases. I don't know if it does make sense to handle them. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 keeping an http socket open. This is not correct. The purpose of a websocket is entirely different, these are not interchangeable technologies. A websocket is not even the HTTP protocol. If course the browser, the server, and any proxy in between needs to support this but I was told that his is supposed to usually to be in place. This is also not correct. I have had many problems deploying a websockets based program. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 very "safe" methods like "comet" that rely on kept-open http sockets. If course the browser, the server, and any proxy in between needs to support this but I was told that his is supposed to usually to be in place. This is also not correct. I have had many problems deploying a websockets based program. I see. So what I have been told by a websocket advocate (who indeed erroneously claimed that websocket is a HTTP protocol and proxies would not need to acknowledge such a new protocol, calling me a fool for doubting this), seems to be wrong :-( . -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 successor technology for the replacement of not very "safe" methods like "comet" that rely on kept-open http sockets. Utter nonsense. Websockets are good when the server needs to push similar data at high speed, no more, no less. When different request for different kinds of data need to be fetched, HTTP 1.1, with its option for keeping the connection open, is more suitable. If course the browser, the server, and any proxy in between needs to support this but I was told that his is supposed to usually to be in place. This is also not correct. I have had many problems deploying a websockets based program. I see. So what I have been told by a websocket advocate (who indeed erroneously claimed that websocket is a HTTP protocol and proxies would not need to acknowledge such a new protocol, calling me a fool for doubting this), seems to be wrong :-( . Very wrong. Always distrust advocates :) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 provides a pipe that both sites can push data in. This potentially might be suitable to allow the server (i.e. the fast-cgi program) to send state-messages to the browser (e.g.in order to create a web-GUI). -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler error passing a Property as a parameter
Am 10.06.2014 09:24 schrieb "Michael Schnell" : > > On 06/08/2014 09:50 PM, Graeme Geldenhuys wrote: >> >> You can't pass them directly as a var parameter, > > > I feel that generally passing a property as a var parameter is not possible, > > It could be possible for built-in functions (such as inc() ) or for properties that don't have a set or get function. > > Of course the compiler could detect these special cases. I don't know if it does make sense to handle them. If you would look at the wiki articles linked by others already which describe the changes and the reasoning behind them you'd know why we don't allow properties to be passed to var parameters anymore. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 communicated via HTTP) stays open and hence provides a pipe that both sites can push data in. More or less, yes. This potentially might be suitable to allow the server (i.e. the fast-cgi program) to send state-messages to the browser (e.g.in order to create a web-GUI). Check e.g. the "leap motion" device. It uses a websocket to stream the skeleton tracking data to whoever wants it. This I consider a good example of the use of a websocket. 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. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 Lazarus gui designer and
hence would-be cgi programs to be tested locally with "normal" Lazarus
means, and allow for "easy"porting Lazarus (and Delphi) programs to be
cgi's.
("Technically" such a "stateful" web GUI widget type could be crafted
based on the "customdrawn" widget type and a java script / HTML5
library that draws the basic widgets.)
IMOH, such a tool would be a great plus for Lazarus to offer, even if of
course the look of such a thingy within the browser would not completely
match the look on a "normal" desktop and certain controls are not
available.
That is why I (at some other place) discussed websocktes.
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 web-interface that can be designed via the Lazarus gui designer and hence would-be cgi programs to be tested locally with "normal" Lazarus means, and allow for "easy"porting Lazarus (and Delphi) programs to be cgi's. This is simply not correct. See the non-lcl widget support. Joost van der Sluis uses it for HTML and iOS design. I wrote an article about it many years back when it was first implemented. Indeed, I requested (along with others) this functionality exactly to be able to do what you claim "would be prevented". Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 infrastructure, using some external GUI designer (AFAIK, FPGUI can do this, as well). But I don't see why this proves that it would not be beneficial to use the nice stuff that is already in place for Desktop purpose. I wrote an article about it many years back Could you point me to same ? Thanks, -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 designing the GUI in Lazarus. (in time with translation of pascal code to Javascript) See the non-lcl widget support. Of course it is possible to do widgets without support of the lCL infrastructure, using some external GUI designer (AFAIK, FPGUI can do this, as well). But I don't see why this proves that it would not be beneficial to use the nice stuff that is already in place for Desktop purpose. Because this nice stuff does not translate to web. I wrote an article about it many years back Could you point me to same ? http://www.freepascal.org/~michael/articles/#nonlcl Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 has a look and feel very similar to an LCL based GUI (I seem to remember that they have a demo on their website). http://www.freepascal.org/~michael/articles/#nonlcl Thanks ! I'll take a look -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 long) > > But my QNAP NAS at home features a Web GUI that has a look and feel very > similar to an LCL based GUI (I seem to remember that they have a demo on > their website). I'm having a feeling of deja-vu all over again- Didn't this exact same discussion not happen some months back? @Michael Schnell: how is the non GUI event stuff coming along? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 environment to chose for any project promising to be more that a one-shot thingy. @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 preliminary stuff done internally). To be decently useful I think updating EpikTimer to use vDSO is necessary. I'm going to test this ASAP. In the other thread I asked if anybody would like to test it and send a list of lacking features. As nobody answered, I understand Thai I am the only one interested in this stuff. I am positive that I'll be able to do some usable code but in fact I have no clue how to have it integrated in the LCL so that it can be used by selecting a WidgetType variable called -say- "ActiveNoGui". But just for my own sake I don't know if this is worth bothering the "powers" with my request for help. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 the GUI and originated by timers and threads). But if "CustomDrawn" would be used as a basis for a Web GUI (provided that this turns out to make any sense), we would need something like the said "non GUI event stuff" in the background: "GUI" events are generated by TCP/IP receive events (to be handled in the main thread, and supposedly fired in a thread that waits on a blocking TCP/IP socket), other main thread events are fired by Timers (I just implemented that) or by standard worker TThreads (already supported by the RTL). -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 > preliminary stuff done internally). Ok. > In the other thread I asked if anybody would like to test it and send > a list of lacking features. As nobody answered, I understand Thai I > am the only one interested in this stuff. Why not put your code on a public repository and post a link? That would probably help give more exposure... > I am positive that I'll be able to do some usable code but in fact I > have no clue how to have it integrated in the LCL so that it can be > used by selecting a WidgetType variable called -say- "ActiveNoGui". I thought that was the entire point of your code but I may be mistaken? > But just for my own sake I don't know if this is worth bothering the > "powers" with my request for help. Well, as you bring up your proposed ActiveNoGui as a solution many times in mailing list threads it looks like you're convinced it would not only be helpful for yourself but for others, too... ;) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CustHttpApp and HP httperf tool
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 Lazarus. .. it looks like you're convinced it would not only be helpful for yourself but for others, too... ;) Of course. (otherwise I would not discuss the issue). In fact, very recently there was a post in a mailing list and I answered to it. But no further comment was given. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
