Ron

Only the simplest webapps are completely stateless, as far as I know. There are two basic ways to store state: 1) on the server, using session control with session data stored on the server 2) on the client, as a session identifier passed in the URL back and forth The second option is what they call stateless, as state is not stored on the server but on the client, so it is really not stateless per se. Please correct me if I am wrong. With Unigui you can do both, but since every form takes an initial loading of a MainModule, it may not be as efficient as with e.g. TMSWebCore, where you only have a bunch of html, css and js files to load. With good webserver preloading and caching you may come close, though.

I made an update system with client and server update modules as regular VLC apps. The client UPX-packs and zips the update file and sends it using FTP to my update server, which unzips and copies the .dep file to the correct deploy folders for all instances on the webserver. When the update server notices an incoming file, it creates a simple text file in the unigui app root dir, which the unigui app then discovers (timer checking) and shows an update message, warning that the app will restart in about 30 seconds and then deletes this text file. I guess you could instead copy the .dep file to another folder and give the user the chance to select when to update, i.e. when to copy the file to the deploy folder, if you like.

You should be able to access the /server by specifying the whole path, like http://domain.com/myapp/myapp.dll/server

To avoid having to specify the .dll file ending you can set DirectoryIndex in httpd.conf: <Directory "C:/appfolder> Options FollowSymLinks ExecCGI AllowOverride None Order allow,deny Allow from all DirectoryIndex myapp.dll </Directory> Alias /myapp "C:/appfolder" This also cleans up the url so the .dll part does not show.

OK, I realize it could be a problem with the hyperserver, as new servermodules might be created at new client connections. Then you need to clear the sessions list when you start or restart the hyperserver, i.e. the IIS or Apache which runs the hyperserver. I use a script which triggers a webserver restart each night at 2AM, and this also restarts the dbserver. In such a script you could clear the db sessions table before starting the webserver. But having the option of triggering an event at hyperserver first init would be nice, as requested.

In the UniServerModule.Create event you can clear all active sessions in the db.

If you have an application (service) running locally on the machine connected to the printer, you can then check your server DB every few seconds to see if there is a print job ready. You can set up a table for print jobs in the DB, and store the jobs there, and when they get printed you mark the row as done. So each few seconds connect to db and run query on all unprinted jobs, and print whatever is unprinted and mark it as printed.

The server is blocking the connection, and you have to specify allowed origin in the server config and restart it.

procedure TTransForm.signalEvent(EventID:integer); begin case uniMainModule.polling of 2: UniSession.AddJS('$.get("http://127.0.0.1:'+uniMainModule.kassePort+'?event='+inttostr(EventID)+'&op='+uniMainModule.initialer+'", function( data ){' + ' ajaxRequest(TransForm.form, ["regEvent"], { response : data }); '+ ' }); '); 4: UniSession.AddJS('$.get("http://127.0.0.1:'+uniMainModule.kassePort+'/regevent.php?event='+inttostr(EventID)+'&op='+uniMainModule.initialer+'", function( data ){' + ' ajaxRequest(TransForm.form, ["regEvent"], { response : data }); '+ ' }); '); 5: UniSession.AddJS('$.get("http://127.0.0.1:'+uniMainModule.kassePort+'/cgi-bin/regevent.cgi?event='+inttostr(EventID)+'&op='+uniMainModule.initialer+'", function( data ){' + ' ajaxRequest(TransForm.form, ["regEvent"], { response : data }); '+ ' }); '); end; end; procedure TTransForm.UniFormAjaxEvent(Sender: TComponent; EventName: string; Params: TUniStrings); var resp:string; begin if eventName='regEvent' then begin resp:=Params.Values['response']; if resp='OK' then begin // end; end; The first function is doing a jQuery http GET to the local webserver doing cross-origin scripting, and option 4 is calling a php script, with 5 calling a cgi exe file, and the first option calling an indy http server running as a windows service. Then just pass along the callback function, and catch this in the ajaxEvent handler, and pick out the response from the php script, or the cgi executable, or the indy server.

"Blocking" refers to whether the function/method returns only after execution is completed, or if it e.g. spawns a thread to do the job and then returns immediately without you knowing if anything at all has been done or not. In case of non-blocking components, you typically have to check a status event to see how things go, or you can hook into some finishing event if that exists. I guess most db-components are blocking, and this should be easy to determine from their documentation. To test things out, just get a free test server and run some tests. You can also do some checking to see if previous changes have been applied, before each new posting, for the most critical sections. Just to be sure.

Synchronization involves the interaction between client and server, so when you are operating on only one side there is no such problem. The only question in this case is if your db access methods are blocking, and if they are they will be executed sequentially as usual. One way to try this out is to simply test it and see what happens.

I have had maybe some related issue, as I am loading some HTML into the frame and then adding JS by UniSession.AddJS, and if things gets mixed up, I just reload the HTML again, kind of starting on scratch. It seems to work for me.

How the webserver running your Unigui app responds to e.g. page1.php, depends on its setup. If it is not set up to handle *.php, then it will probably not handle it, and not trigger your Unigui app. You can set up a redirect, so that any file you wish gets executed when page1.php is requested, and that request may be added as a parameter, which you may then pick up in the Unigui app and respond to, producing some specific html that you want to give the bots, if that is the goal. As mentioned above, you may respond with some predefined html by using HttpCommand or you may respond with the complete application by doing some automatic login in the background if a certain parameter is used, and directing the bot/user to a specific page/form if you want to.

I use a socket.io Javascript client, and a Node server running a socket.io server. The client is set up in a UniHtmlFrame, and also doing authentication using AjaxCallback. It works, and is not that complicated to set up. But native components, client and server, would be nice. Guess the fallback stuff used by socket.io is needed, in case there is no websocket support in the browser - then it uses long polling.

The dangerous thing with invisible form code. Better to have it with the rest, and inject it on create.

A typical challenge, and the downside of a context menu is that you have to know about it, as it is not visible at the outset. Buttons with text makes it difficult to build a dynamic menu, but then you have toolbars which give more flexibility. A vertical toolbar with only icons initially, where it expands to a menu horisontally with text at hovering...aligned right. I see the need to put icon buttons into a memo field, like the editors.

I would look for some kind of concurrency issue or a timer that gets fired after the form is closed, or some reference to an object on the login form after it is closed. Just because the code worked earlier, it does not mean it was without flaws, as the previous version of the library could have been more forgiving in some cases and then getting stricter as loopholes are closed. What is your code as you click the login button?

Sure, we all understand that. I waited about 3-4 years running a small app with Unigui, before I took the chance to migrate a bigger app. But during the years since 2012 I have had only great experiences with Mr. Farshad, and I realize what kind of personality he is. Introvert, hard working, disciplined, organized, systematic, goal-oriented etc etc. Time and again I am taking myself in being highly impressed by the work he has been able to keep up, over these years. I realize this is unusual and that he has done something that no other company with tons of resources has be able to do: taking a very complex technological issue and making it simple. People are different. Some make a mess no matter what they do, while others make it work consistently. I am 100% sure about one thing: Mr. Farshad is not taking this issue lightly. He is not going to take any chances after all this work, as that would totally contradict all previous efforts. The reason some things might take a while to get addressed, is probably due to his diligence, wanting to cover all aspects involved and deliver a great solution. That is what I believe. Surely, in theory anything might happen, and life comes with no guarantees. Just have to live with that.

This you can solve by adding some URL parameters, which you then pick up and use for automatic login. This may include some random code which has a time limit and may only be used once for login, and gets cleared in the db afterwards.

Even though I agree that a plan B is always called for, I have never been scared due to the apparent lack of such in this case. I have never lost a second of sleep over this issue - but maybe I should have. So far it would not have amounted to anything, though, and would only have been a waste of time. Surely, life does not come with a promise of being risk free. But past events predict future behavior, and risk is often related to idiosyncratic issues. Based on this I have the utmost confidence in Mr. Farshads ability to stay in the loop.

I thought about the same, but then wondered if that would create some future limitations. But both could be available, with one overriding the other. E.g. if there is a config file, that overrides servermodule settings.

Agree, it's really not reasonable that it should take 12 hours for a message to be visible on the forum on the other side of the planet, but so it is...Just have to live with it.

It looks at FileVersion, not ProductVersion, and if you set this to "Auto Increment Build Number" at the Version Info setup page, then things will happen pretty automagically. I find this very handy and informative, so I can know that updates has actually been loaded or purged. At development you just Ctrl-F9 to compile and test until happy, and then Shift-F9 to build with an increased build number, and upload.

I have many hyperservers on a single VPS, each in a different folder, and the start ports being set so they do not overlap. Nothing else should be required as far as I know.

You should be able to add an IdHttpServer in the UniServerModule, and process the http requests that way, but on a different port than the server application of course. This demands that the application is loaded, which will not happen until the first mainmodule request is made, as far as I have experienced.