Hi Thomas,

re: native apps with embedded data engine

That's what I wanted for the first few years -- and then the field changed. Native apps are losing ground to PWA's which are essentially what Lianja offers, in addition to Cordova/PhoneGap. A full app runs in a browser. As for data handling on the client -- agreed. I don't do it there. I write the data stuff on the backend, put the name of the routine in exports.conf in the app directory, and call it with JavaScript parameters in the "web" app, it gets executed on the backend (in Lianja's nicely-extended VFP) and returned as a JSON string. If the returned has to go onto the page, a single command does that.

There will be local data with auto-syncing a couple of versions from now: it's in the roadmap. The next release after the one in beta will be managed Lianja on Amazon, at what are projected to be very reasonable costs (but I don't know them, so can't say one way or the other as yet).

The only reason to use Cordova is to go through the App/Play store. It's the same app. And it's just pushing a couple of buttons once you've set up your App/Play store credentials (with Apple, you need to have a little Mac to run this on, due to their requirements). Likewise for Electron (desktop: until browsers can safely access local machines, Electron has the libraries to access anything on the machine). Electron also just a couple of fields (like App Name) and push a button.

Even my mobile banking account isn't a native app: it's PWA. That's where the world is going.

A lot of the above got added after you veered off in your own direction. Lianja keeps responding to developer needs as they arise. The latest improvements will include a way to integrate a KMS into the Lianja SQL Engine. Combined with multi-tenant databases (the code remains the same, the database name refers to the tenant), this opens the door to meeting modern security requirements for how data is stored (it can be encrypted as needed, by table and client) while handling multiple clients on the same web server. Yours truly had the need, and now it's coming.

BTW: if you need a page designed specifically for a form factor, e.g, a phone, you now create an "alias" page. Your code still runs, even when accessing the original page.section by name.

Need to upgrade your cloud app? Create an LPK (Lianja Package) in the UI, deploy to the Packages folder on the Lianja Cloud Server holding the app. When the Cloud Server isn't busy, it suspends the threads, installs the update, and then picks up processing calls. You can put in custom programs to update data. Creation of that data update for you is in the works.

There's a lot more in the UI stuff that's been done, and even more coming. A big one is Components. Want to use a Kendo UI control? Put it in a Webview (JQuery is already present), hook up the Kendo controlsource to a JSON object returned from a VFP call to the backend, and then save that as a component and use it anywhere, as though it were a single control. I haven't seen that yet of course: it's on the roadmap. It can be done now, but not yet made into a component.

Lianja, as a platform, keeps on growing as developers make the case for what's needed to build and deploy their apps.

Hank

>>Thomas,
>>
>>> xBase++ (including their server-side web page generation) seem to offer little above vfp9+FoxIncloud for my use cases.
>>
>>I wonder what this means…
>
>Basically for the use cases I code[d] for in vfp moving to xBase++ makes no sense.
>Reasons: end customers have Win server licenses already, so building/supporting a Linux back end is not a great benefit to end user (read customer buying app from my employer). If Metin sells to thousands of restaurants at cheap price, cost savings from eliminating Win server cost perhaps are a stronger argument for him.
>
>If Lianja had offered a native android client including embedded cursor engine, that would have been reason for me to stay there.
>>
>>Server-side web page generation is a 20 years old tech while FoxInCloud creates an interactive AJAX Web Application with thousands of controls and events out of an existing desktop application.
>
>From what I gleaned, xBase++ is somewhere near asp.net in model, but following basically a "chatty" server directly controlling the browser on client device.
>
>In new dev I (sadly) follow the same model in Java (less discussions if bought out, bringing other partners onboard, payed for by less snappy development), but as I follow "schema-driven" + "DB-first" development not that much slower compared to developing in vfp.
>
>I personally aim for a tech stack with [dedicated] datastore usually instantiated on client (State or Vuex in Vue, Redux or MobX in React, mini-mongo in Meteor) or (if security demands it) on the server. Benefits: Targeting more PWA-like architecture, option of offline work, moving from "chatty" to "chunky" mode of client-server communication, as most GUI changes are fired directly on changes in client data store, not after server call....
>
>That datastore should be "lean" IMO, comparable to vfp cursors, NOT ORM-generated object graphs, as those can suck up CPU cycles like crazy. Fat chance at the moment, I know....
>
>Back to xBase: they claim to have more than PHP from turn of century: websockets able to drive RPC calls or XML/JSON endpoints done via compiled-to-machine-code (more secure/faster/non interpreted compared to classic asp) server pages - more ASP.NET than classic .asp.
>
>Dynamic sites, data-driven sites, generated sites - but as I argue to stay in vfp and add FoxInCloud and NOT move to xBase, why go into detail?
>Leave out areas where I consider xBase++ has benefits above vfp like multiple inheritance, ISAM on Postgres or Linux backend ?
>Not my style ;-)
>
>>
>>How can you compare these, and what is above what?
>
>You gather feathers in the hat / black eyes on both approaches, weigh and count them according to your use case and decide ;-))