Thierry and others: Let me get a few things straight here. I am not attacking the product, I was even advertising it as a choice, also elsewhere.
In his last answer, Thierry, you now focus on the advantages of server side execution of VFP code. It's fine in regard to protecting intellectual property. But that kind of thinking is only half way true. MySQL is a fully open source product and still has a big revenue, this is not depending on closed sources, on the one side. On the other side, in EZLogics case discussed here the main business is selling products, not the shop web app and it's code, also not the data, which is no secret, the products and their stock need to be readable and searchable by customers. In my case a customer won't put up formulas - their core knowledge - to any hosting, not even self hosted.
You explain very good, why response times are an issue with FoxInCloud, every code you put in a VFP form doing things on already loaded data by working on cursors, arrays, collections and controls is done at the client side, when runnning on desktop, and is not involving an SQL server or file server or the network. That is not translated to javascript/ajax, that is now executed at the server side, and that is exactly what I meant. The gain can be, if your application server now is close or even local to data, you can even accelerate the data access as you can with a manually written web application. The typicall client/server nature is positioning core business logic nearer to the data and only UI (html forms) are client side. But you may gain less than you lose, in regard to UI response times you can get much better results by manual conversion or reimplenmentation in client side javascript, disregarding the closed/open source factor. Of course that conversion costs both more time and money. Neither way is a solution for everyone, you have to make that decision per case. Another system typically is needing another interface anyway.
FoxInCloud is very usable, if you can install it on a server with low ping times, because then this effect is not hurting that much, so it's a good thing to use in intranets, for example, as intranets base on an IIS server hosted in the LAN and with a good response/ping time. If you want to use an application global, you have to host it and its data and others have said what they think of that. Some/most clients will be remote users (in the natural meaning of the word). It then depends on what response times are acceptable. For users used to the desktop solution dragging&dropping data around, or moving it from one list to another in multiselect with buttons or double click you won't get the same smooth behaviour with FoxinCloud. In my case this and an ActiveX ExGrid Treeview is making up much of an enterprise application, which matured for 30 years of continually development failed to work with FoxInCloud and I would have been surprised, if this large project had worked out.
I didn't and don't say FoxInCloud is for no one, but it has limited use for me and my customers and is no universal solution. I repeat myself, if I add, that it only helps for staying at VFP. It can be a fast solution more than a pain reliever, but in long terms you or your customers won't find someone continuing fox development after your own retirement. Many companies disregarded that fact and still are happily keeping dos apps up and running, so you can also disregard that as a mute argument, but it also caused the downfall of VFP itself and it won't continue forever.
Bye, Olaf.
