PHP version matrix "spread"?

Howdy!

I am hoping to begin duplicating several environments that my current client uses - one of which I believe a classic LAMP installation. There are other environments as well, yet to be discovered. I am hoping tomorrow, Feb. 3, 2020, I will find out which version of Linux, Drupal, PHP and (most likely)) Apache is in use.

The goal is to build a bi-directional data process between Linux, Windows, Azure and who knows what else.

I will either be using a Docker Machine inside of VMWare or if I get lucky, a simple VMWare machine.

Given I do not yet know what version of PHP is in use I thought I could at least ask what the "spread" of PHP versions is that the current version of Lianja, which is 5.2 is officially supported. A bracket, if you will.

Thanks!

Doug

Hi Doug,

PHP is only supported as a desktop scripting language and is an old version 5.3.8. There has been no demand to upgrade this as its purely used for scripting the Lianja Framework classes.

The main scripting languages supported are Lianja/VFP, Python, and JavaScript/TypeScript.

It is included so developers with PHP development experience can code desktop Lianja Apps using the Lianja Framework.

However, existing http URL's that run PHP can be embedded in Lianja UI WebViews as the PHP executes on the remote server not the client.

With regards to using docker, Lianja Cloud Server requires an ISV license in order to run it in a docker container as these can quickly escalate in numbers in a containerized environment.

You will need to run the Lianja Cloud Server in a VM until Lianja 6 is available (Hosted Cloud and Docker support).

There are docker limitations when running docker on windows insofar as no 32-bit applications will run, only x64. Thats why if you look in the roadmap there is a windows x64 port planned.

Hi Barry,

So, the basic approach is that PHP, or any of the other scripting languages, in so many words "run" Lianja processes rather than Lianja being able to call PHP processes?

I am hoping that I can leverage Lianja as the controlling entity. In this case, "pull" from Drupal and also "push" to Drupal, rather than having Drupal "push" and "pull" data via Lianja.

I suspect I am missing something simple. I will revisit the docs. I am not too worried as there are many ways to "get there," but I must admit it is a great 'sell' to be able to say that Lianja can grab data from Drupal, push it to Azure, grab data from Azure and put it back into the VFP-based desktop product and Drupal or other repositories while the new solution is being stood up. Being able to support both the old and new ecosystems simultaneously is huge, I'd think.

My goal is to promote Lianja, not PHP. :)

The environment I find myself in is quite diverse and Lianja looks to have exactly the right approach with its script support.

Thanks again!

Doug

Hi Doug,

No.

Lianja/VFP, Python, JavaScript/TypeScript, and PHP are all embedded in Lianja.

WebView sections and gadgets are embedded browser UI elements.

I'm not sure what you mean by "push" and "pull" to drupal.

A WebView can have a URL that points to a remote site, a local URL, a Lianja/VFP (.rsp), Python (.pysp), JavaScript (.jssp) or PHP (.php) file set as the "filename".

You can use the "networkrequest" class to "get" and "post" data to remote PHP sites.

Theres many ways to do this.

Barry,

Ah... Embedded. Got it.

"Push" and "pull" are terms I learned further back than I care to think about :). In 1996 I worked with Craig Church on a gig in Palo Alto - The EC Company. We "bolted together" EDI and the ACH feed. We sent real money from one bank to another, using CompuServe no less. In the banking industry, this is important. Do I pull money, and have the right to do so, or push it?

Three of the main components in involving a Foxpro 6 application, Drupal on a LAMP (Linux, Apache, MySql & PHP) system, and Azure.

The end goal is to have everyone using Azure and a .Net/ASP application.

There are three stages I expect we will go through. And, where I'd like to start using Lianja.

• Triage the existing codebase as needed.
  
  • Extract all hidden code and "magic numbers."
  • Implement them in SQL (Lianja, MS, Postgres, ?) as stored procedures.
  • Normalize data and processes.
• Develop a process that allows for bi-direction data flow.
  
  • Use Lianja to 'pull' data from Drupal (PHP)
  • Use Lianja to 'push' data to Drupal.
  • Use Lianja to 'push' data to SQL. (This allows for an agnostic normalization platform.
  • Use Lianja to 'pull' data from Azure, Drupal, VFP, and SQL as needed.
• After thorough testing turn the old system off

I am not privy to the expense, but I do think there might well be a cost-benefit having Lianja intimately involved in the intermediate stage, at the least. The project looks to be a minimum of two years, most likely more. And, I do think there is a possibility of increasing ROI in the process, in large measure, I am hoping based on how well I can get Lianja to work in this scenario.

There is a web-facing presence, and, candidly, I do think Lianja would also be a great fit vis-a-vis its ability to make the interconnectivity as seamless as it does. (Nice!)

I am hoping I can use existing PHP code and leverage a connection into Lianja, or from Lianja to the Drupal API. And, the same for Azure, and, of course, VFP. I know you have the ODBC side which is where I'll start.

And, I cannot imagine that any code, like PHP, does much more than basic input/output. Drupal itself would handle all of that and I honestly do not care to spend time there. I just want to get my hands on the data stream, and m looking to leverage Lianja.

You mentioned licensing, which I get. What I am doing is reproducing all of the environments on my new laptop - a Lenovo P73 Xeon, 128GB RAM & 3 2-TB solid-state disks. So, VMWare and/or Docker running in VMWare, which I can do now - if I need it. I don't think I will as I ought to be able to run everything in VMWare "straight up." Azure? Well, as usual, MSFT is a pain in the backside. :) There used to be a desktop-based Azure machine, but I believe these days one can only find those in a Docker Machine and given that Docker is a Type 1 hypervisor and VMWare a Type 2, they do not work well together. Fortunately, there are workarounds while they finish sorting out how to make them work together.

Thanks, Barry! Hopefully, that will help a bit.

Regards,

Doug