Hi Hank,

>A lot of the above got added after you veered off in your own direction

big difference between our situations is that your job is for a company living off current vfp app guaranteing a defined work load in Lianja.

In your shoes there is a good chance I'd have stayed with Lianja - probably making a bit of a pest of myself cajoling/pushing for "native apps with embedded data engine" to be realized - and in the end finding a way to sponsor "preferred development" within a certain time frame either by contracting Barry directly or - preferred if possible - increase share capital a tiny bit to show dedication, allow Barry to implement with less pressure and reap some earnings in the future ;-)

But here most of the time I am contracted as hired gun (but still able to think in architecture plans) whenever something in vfp is not possible for normal employees. When client company is large, often the plans to move to web or Java are already budgeted - arguing for Lianja would be a waste of time. Smaller clients ask me for a rewrite / streamlining of their fwk, but usually stay in vfp as they perceive no tangible benefit in porting - web could be handled by FoxInCloud or West-Wind, no benefit for native tablet/iPad apps compared to web since data munging is identically done on server.

Being able to offer local embedded dataengine for handheld apps would have been the thing IMPOSSIBLE for the others working somehow on schema-based RAD tools. Consider loading a SQLite database file or zipped Lianja table dir with lookup data for car parts in handheld devices to calculate repair cost directly by tapping instead of viewing accident and typing remembered/jotted down items in when back in office. Database file updated monthly by download when on WiFi. Persisting local data of accident (little more than an order list) when online - nice for LiFi networks ;-)

What do I do instead if doing "vfp-typical" tasks ?
As I follow much of your preferred dev style (heavy reliance on schema/data dictionary/validation rule engine "elevated" to all layers necessary) I still reap many of your RAD benefits if implenting in Java, although find myself battling with overgrown ORM stacks due to the Java way of trying to follow Ruby on Rails "convention over configuration" mantra, which resutls in ridicolous effort to translate method name of bean into specific action on DB instead of applying simple rules to names according to patterns defined in advance. UUUUGH when debugging, molasses for CPU speed...

Benefit: no need to spend many (often unpaid) hours defending the implementation tool to new customer/partner/buyout prospect.
Drawback: burning lots of CPU cycles sometimes turning into real fridge or nespresso walks due to time needed for compilation

But those walks are paid, and if I gather enough energy again to make push/sit/chinups again during those times, everything would be great ;-)

More time to ponder hare-brained new biz ideas brought to me - might find something to work for at no/low hourly wage but chance of winning big via share buyout ;-))

Minimal time working on bloody edges (for vfp): still big iron comm/rpc, current SOAP, perhaps soon again roboting web access (after pioneering that in IE4, when the disaster named IE3 was behind me), doing odd jobs difficult to explain to normal coder ;-)
But that pond is diminishing - and I do not see Lianja pond for dirty old shark...


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

>That's where the world is going.
True. I am uncertain if current generations ability for complex thought is diminished or current tools for small screen web are insufficient ;-)
But the world is going directly to JS - remember the things we wrote about, offering benchmarking suites for our JS on different HW?
Google has Lighthouse and filtered nice statistics from it comparing "typical" times for devices, Addy Osmany has them often referenced.

No need for Lianja in ***that*** world, as my idea of "hooking up" Lianja with larger customer bases already would be only "me too" in Vue.Js after Weex and Nativescript integration efforts are already done.

>Even my mobile banking account isn't a native app: it's PWA

For that you do not need a datamunging layer between big iron data store and client - writing out between half a dozen and full dozen csv lists would be enough, not even JSON transform needed. Read into array, "munge"=filter/sort with lodash as no joins are needed and bind to controls.

Yes, Barry has speed and architecture knowledge enabling him to implement more than 20 to 50 times the output/enhancement of "normal" open source coder. But there are hundreds of those coders - and the heads of projects (think Evan You, Dan Abramov, Osmany) have probably administrative tasks slowing down their code output and decide it is worth NOT to code, even if result is better than normal coder...

So unless Lianja offers me a use-case specific edge, I'll stay within the larger pond of "pure" Java/Javascript users without inflating the stack returned to customer in size, complexity and price.

Quick question: has the Lianja HTML control similar "automation" capabilities as MS WebBrowser control or createobject("InternetExplorer.Application") ? Perhaps coming up early next year is decision of going with IE again, trying Selenium2 interfaces or testing if JxBrowser is worth ~2K license cost - if Lianja forwards CEF bindings nicely integrated, might be an alternative if contract is large enough to warrant return ;-)

And give me a holler if mobile OS native apps with embedded data engine are not only on roadmap (again...) but are synched on devices.

regards

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 ;-))