1. Check Compatibility: Review the list of encryption algorithms supported by the newer version of libssh2 to ensure that it includes both the old algorithms required for existing connections and the new algorithms required by your partner's SFTP server. You can usually find this information in the release notes or documentation of the updated library.
2. Customize SSH Configuration: If the updated library supports customization of SSH configuration, you may be able to explicitly specify the list of supported encryption algorithms. This allows you to include both the old and new algorithms required for compatibility with existing and future connections. Ensure that your configuration aligns with the requirements of your partner's SFTP server.
3. Testing and Validation: Before deploying any changes to production, thoroughly test the updated library in a development or testing environment. Verify that it can establish connections with both existing and new SFTP servers without any issues. Pay close attention to encryption algorithm negotiation during the SSH handshake.
4. Fallback Mechanism: Implement a fallback mechanism that automatically switches to the old version of libssh2 if the updated version fails to establish a connection with existing SFTP servers. This ensures continuity of service while you work on resolving compatibility issues with the updated library.
5. Communication with Partner: Engage in communication with your partner to discuss the changes they've made to their SFTP server and ensure that you have a clear understanding of their requirements. They may be willing to provide guidance or assistance in resolving compatibility issues.
6. Consideration of Security: While maintaining compatibility is important, prioritize security considerations when making decisions about encryption algorithms. Ensure that the chosen algorithms meet security best practices and compliance requirements.

How does the introduction of vector usage in ObjectScript impact the performance and functionality of database operations?

Amazing post. Congrats....

Thanks all

Thanks Semion, one last cry, won't NoObjectScript be considered? Thank you very much for your attention and sorry for the inconvenience.

Hi Semion, i made some changes, I added a video and the link to the article in the contest, I changed the name of the file that was as a sample to NoObjectScript.py, in the video I show its execution and demonstrating the usability of the libraries in a FrontEnd.

I understand, it would be more interesting to leave just the Python part like this file without the ObjectScript, but I would have to generate a new image in Docker to remove it, and unfortunately I'm very committed to time right now, for a first Contest it will serve as a learning experience and a lesson, if you can consider something as it is, great, if you can't, that's fine, I'll dedicate myself more to the next one, I'll change this one as soon as I can. Thank you very much for your attention and explanations.

My initial idea was to create a kind of template for future changes, where in the SRC folder there is the project with Python embedded in IRIS and in the Python folder there are two files, one that calls IRIS through Python and the other just the pure Script that runs directly in local or inside Docker with Iris. But I believe that the idea of ​​doing something more comprehensive ended up generating more confusion than solution, this is the first time I have participated in a contest, I will refine it more the next time.

Yes, there are both implementations, in the Python folder, file sample.py this is the construction only in Python without ObjectScript. By the way, I also made an article, I think I linked it to the app.

Thanks @Evgeny Shvarov for sharing technological bonuses results.
Please note that iris-python-machinelearn application has  Docker functionality and the last update NoObjectScriptLine too.
Thanks again.

Congratulations

congratulations to the Winners

Very helpful post, thank you!