Hello,

I'd like to understand why dbg-php.so is so much picky about versioning?

I mean, there is a choice of architecture, of course, but beside of that :

• PHP version : couldn't a single module manage all supported PHP versions?
  Even if it results in a file 10 times bigger, there are some other PHP modules bigger than that.
  
  
• More important, debugger version:
  I can understand that a DBG 9.1 module could be incompatible with a 9.3 client.
  But is it really impossible that a DBG 9.3 module could support a 9.1 client?
  
  I mean, it can sometimes happen that several PhpED users want to connect to the same server whereas all of them do not (and cannot) have the same PhpED version.
  Having a good ascendant compatibility would avoid them many issues, they'd just have to install the most recent of their versions.
  
  
• Couldn't an existing module be able to upgrade itself once installed?
  
  It's really painful to have to return digging and get one's hands dirty in all servers each time we upgrade to a new PhpED version.
  Also, in case of Linux (main distributions), for example, there are packages for handling this kind of upgrades.
  dbg-php.so (like xdebug for example) could even be distributed that way.

Gingko

Different PHP versions couldn't be handled by single debugger library because php ABI dramatically changes from version to version -- structures, functions, callbacks etc, order in which they are called, sometimes layout of callstack etc.
Problem with debugger is even clearer - in new version we add new features or fix some old bugs. Just because of that you'll have to update debugger or it wouldn't handle IDE requests correctly. It means that new IDE can't work with old debugger. For the same reasons old IDE can't work with new debugger because it wouldn't understand new or altered debugger response.
As of automated update, I think you don't want this thing on your servers - because dll or shared object can't be running on its own. It needs some process -- binary to load update _and_ what's more important it would have to be running under root privileges to be able to restart web and make updates into effect.
If you have many servers to work with, perhaps CI/CD would work the best for you and deploy changes efficiently and in automated way.

I don't know who you manage your upgrades, but new debugger are always necessarily aware of what were old IDEs.

This should make things easier, as I don't feel protocol changes that much, at least across minor versions.


I can imagine several ways to work with these limitations.

One of them could be replacing the debugger with a master module handling only connections and version identifications, which in turn would dynamically load (and sometimes unload if switching is needed) a child module chosen among a collection located inside a dedicated directory, downloading missing ones on the fly if needed.

See “https://tldp.org/HOWTO/Program-Library-HOWTO/dl-libraries.html” (how to load/unload libraries dynamically on Linux) (Windows has definitely its own way to do the same).

This dedicated directory could even be something like “/home/<username>/.nusphere” (which can also be created on the fly), don't matter if several users may have several copies of the same child module, this should solve all access right problems.

The directory (with enough access rights) could also be selected by proper additional configuration strings.

No need to have its own process, this could be made inside the existing processes, just being triggered by the first debugging call.

At worst we would loose a few seconds at the beginning of the debugging session if downloading is needed.

Such strategy let's me thinking about the way Microsoft handles the loading of it's debugging symbols, inside Visual Studio or other applications.

But you could also just have your own repositories of Debian/Ubuntu/Redhat/Arch Linux packages containing debuggers, and installing and upgrading modules using the standard way. This should need ascendant compatibilities of the debuggers, however (see first answer). Many applications do that without needing to send packages to official repositories.

Gingko

libraries can't be just loaded. They are loaded into their processes. In this case, they are loaded, for example in php cli process. You start php cli, it loads debugger and you want debugger doing what? ping nusphere for new version and download it from there? Every time? or you want to configure persistent storage so it would store timestamp when it pinged last time and throttle activity? Ok, it's hard for us, not easy for you, wouldn't work at all for multithreading web servers, but anyway, even if you want to do this, majority of large customers do not. They have their own security teams that wouldn't even permit modules that can run such activity like replace binaries on the fly. This replacement is not possible in most if not all configurations. I'd highly recommend you to do the same -- no web running processes should be able to alter any code (binary or scripts) on your server or it will end up very badly for you, sooner or later.
For updating servers, people invented CI/CD -- this is a proven way.

Regarding minor versions, php ABI is frozen (by contract) only in sub-minor updates, such as 7.4.0 -> 7.4.1. It dramatically changes in minor updates like 7.3->7.4. There were times when subminor update also broke ABI -- for instance 5.2.0 -> 5.2.1. So if you have modules for php-5.2, they will definitely crash if loaded with php 5.2.0. Fortunately this version is not available in any major distros. This is how it works there, there is nothing I can help with, sorry.

No need to ping anything.
Client connect identifying its own version, module check if it has a child module for that version or not, even if it is not the latest one, it has to load the one corresponding to the client.
Which is expected to be available on your server.

If you type "sudo apt upgrade" on a Debian or Ubuntu server, you will likely upgrade many binaries nearly on the fly.
With security checks, of course.
Your repository would certainly have to implement some security checks also.

And if new module (there will likely be only added binaries, never replacements) are loaded inside user accounts, they will have only access rights to these user accounts so risks would be limited to that accounts.

Regarding security teams, I think that it's up to them to choose if they want that or not, you could always offer alternate methods if they don't want.
But debugging itself is already a security issue.
Large customer will likely forbid it in production servers.
Actually I don't know CI/CD. Please explain how it could help.

Currently I just use rsync in order to sync across servers.

I spoke about minor versions of PhpED clients and debuggers, not about minor versions of PHP itself.

Gingko

Debugger should be considered as a part of PHP because it's tightly integrated into PHP core. If PHP ABI changes. debugger has to be changed too. This is how debugger is updated from 9.2.8 to 9.3.1, for instance, or from 8.2.11 to 9.0.0. In this case minor and/or major version number is changed. If debugger is changed by the other means, like fixes, only sub-minor version is updated, for instance 9.3.1 -> 9.3.4. In this case it remains backward compatible.


basically it means some agent running on each server and some infrastructure that pushes changes and tracks how they are propagated with an easy way to 1) check whether changed server still works and 2) to roll changes back if it does not or roll it back for the other reasons.
There are some online articles about this approach. I can point out to just one for beginning https://www.infoworld.com/article/3271126/what-is-cicd-continuous-integration-and-continuous-delivery-explained.html

This way you'll get full control on your servers.
We don't want to do that for many reasons -- security, resources, support etc. It's not our business to update 3rd party servers. With client software like IDE, it's doable, but not for the server infrastructures.[/quote]