Project structure clarification

[DRSDavidSoft]

Question

So basically, this project has two components according to my understanding, and PHP is used in combination with Electron.js (or later Tauri), and the actual OS APIs are consumed by Electron in this alpha stage. PHP doesn't use FFI or some other technologies to communicate with the shell.

This gives me two questions:

1. First, surely you can use this electron-plugin repo with other backend technologies than PHP, as long as they are able to make POST requests here?
2. Wouldn't you prefer to implement FFI and/or COM objects in PHP to communicate with the OS, such as Windows? For example, PHP supports communication with WMI and the shell objects, which seems mightly more efficient than inter-process communication by the means of HTTP APIs.

[mpociot]

First, surely you can use this electron-plugin repo with other backend technologies than PHP, as long as they are able to make POST requests here?

That's correct. As of right now, the electron-plugin package simply provides a HTTP API that any technology can consume.

Wouldn't you prefer to implement FFI and/or COM objects in PHP to communicate with the OS, such as Windows? For example, PHP supports communication with WMI and the shell objects, which seems mightly more efficient than inter-process communication by the means of HTTP APIs.

I don't think that the overhead of a local HTTP API call is very noticeable.
Do you mean that the PHP binary communicates directly with the electron binary in order to avoid the HTTP roundtrip?

[osc2nuke]

Question

2. Wouldn't you prefer to implement FFI and/or COM objects in PHP to communicate with the OS, such as Windows? For example, PHP supports communication with WMI and the shell objects, which seems mightly more efficient than inter-process communication by the means of HTTP APIs.

Unless i misunderstand your question, you can activate COM support in php.ini for Windows in:
C:\your\Laravel\project\vendor\nativephp\php-bin\bin\win\x64\php.ini
To make it work you have to add it manually (as it is missing in the list ):
extension=com_dotnet

However the php_com_dotnet.dll is provided with NativePHP in the ext directory :
C:\your\Laravel\project\vendor\nativephp\php-bin\bin\win\x64\ext\

PHP MANUAL : COM and .Net (Windows)

Then you can use as:
$MyCOM = new \COM(); or $MyCOM = new \COM('APPLICATION STUFF HERE');

Regardless if i misunderstood the question or not, loading required extensions perhaps should/could be done in the
#Customize php.ini

Perhaps with an Array
E.g.:

    public function phpIni(): array
    {
        return [
            'memory_limit' => '512M',
            'display_errors' => '1',
            'error_reporting' => 'E_ALL',
            'max_execution_time' => '0',
            'max_input_time' => '0',

            // Dynamically load alternative extensions
            'extensions' => ['gd','com_dotnet'], //Etc...
        ];
    }

PS: i have no experience in how or what can do and what cannot do with the COM class. I came across this by accident, believing i could control VLC-player on my machine .... but it not works like that. (*crawling back humble to my cave)

[DRSDavidSoft]

Thanks for the in-depth explanation.

I was curious how specific shell commands were executed by NativePHP in Windows, for example moving a file to the Recycle Bin. It seems that the actual trashing of the files are done by Electron rather than PHP itself, so you are making a POST request using the Laravel "backend" to Electron which runs a local server, thus achieving what I called "inter-process" communication, i.e. between Electron and PHP. After Electron receives such requests, it actually performs system/shell commands.

What I meant by using FFI and/or COM/.NET extension was meant to be a replacement to this scenario that is used in NativePHP. So, instead of relying on Electron to achieve system commands, you'd do it natively in PHP by calling the appropriate system API calls through the DLLs provided in Windows. In other systems (i.e. Linux/macOS) something similar can also be implemented.

Now, in your answer, it's possible to still call system APIs through FFI and COM/.NET, yes, but the APIs provided by NativePHP still will be directed to Electron for processing, as I understand it.

@mpociot Great effort by the way, I'm following NativePHP's development with excitement 👍🏻

[DRSDavidSoft]

@osc2nuke Does it have to be VLC? I achieved something similar using MPC-HC's APIs. I believe VLC could do something similar.

[osc2nuke]

I have "learned" 'something .............. and i can elaborate on it in 'My experience in coding' ... short answer:

You ABSOLYTELY do you DO.
There is no limitation and nothing should hold you back.
The ones creating the 'Engines' are the REAL Masters.
We should salute them :

[osc2nuke]

@osc2nuke Does it have to be VLC? I achieved something similar using MPC-HC's APIs. I believe VLC could do something similar.

I have no idea but the GUYS over at VLC provided us with:
https://wiki.videolan.org/VLC_HTTP_requests/

The social aspect of these kind of services are:

Here i call them to HELP ME out:

    public function videoPlayer(Request $req){

        $video_id = $req->input('video_id');

        $video = DB::table('channels')->where('id', $video_id)->first();

        $client = new Client();
        $client->request('POST', 'http://127.0.0.1:8080/requests/status.xml?command=pl_empty',[
            'auth' =>[null,'janice'],
        ]);

        $client->request('POST', 'http://localhost:8080/requests/status.xml?command=in_play&input='.$video->url,[
            'auth' =>[null,'janice'],
        ]);

        $channels = DB::table('channels')->where('slug', $video->slug)->get();

        $avatars = [];
        foreach($channels as $avatar){
           $avatars[$avatar->tvg_name] = \Avatar::create($avatar->tvg_name)->toBase64();
        }
        return view('index', [
            'channels'=> $channels,
            'avatars' => $avatars,
            'group_title' => $video->slug
        ]);
    }

PS: "Janice" is my daughter:

[simonhamp]

instead of relying on Electron to achieve system commands, you'd do it natively in PHP by calling the appropriate system API calls through the DLLs provided in Windows.

You don't even need to do this. For many standard system calls that PHP is already capable of handling across platforms, you can simply write the necessary PHP code (e.g. unlink('a-file-i-hate.mov')) and let the interpreter handle it.

The interaction with the 'backend' (in this case Electron) is there to enable the other cross-platform parts that aren't well-built across the PHP ecosystem, such as Window, Taskbar and Menu management.

Tools like Tauri and Electron are abstracting away much of the complexity of this across all the major platforms and we simply need an interface to be able to communicate with those features from PHP for some things, not all.

In Electron this is currently via a HTTP API which relies on a web server, as it's convenient and accessible. However, we are exploring other ways to do this that do not require web servers.

In any case, the idea will be to have the solutions work as similarly as possible across platforms to minimise the support overhead of having multiple implementations (e.g. COM on Windows vs FFI on Mac, for example).