Merge remote-tracking branch 'origin/topic/awelzel/python-websocket-w…

…arning-banner'

* origin/topic/awelzel/python-websocket-warning-banner:
  docs/python: Point users at WebSocket

CHANGES

@@ -1,3 +1,17 @@
+2.8.0-dev.51 | 2024-03-19 15:28:32 -0700
+
+  * docs/python: Point users at WebSocket (Arne Welzel, Corelight)
+
+    Users on Slack somewhat regularly ask questions around how to use the Python
+    bindings and finding quirks with it. Just for us to tell them they
+    should be using WebSockets instead. These might not be perfect, but at
+    least we're open to hear feedback and improve them, which isn't
+    necessarily our stance for the Python bindings.
+
+    Put up a big banner to redirect users into the future. Seems "warning" is
+    warranted given our reluctance and future ideas around deprecation for
+    the bindings.
+
 2.8.0-dev.49 | 2024-03-15 22:18:06 +0100
 
   * CI: Remove CentOS 7 and Debian 10 builds (Christian Kreibich, Corelight)

VERSION

@@ -1 +1 @@
-2.8.0-dev.49
+2.8.0-dev.51

doc/python.rst

@@ -4,6 +4,16 @@
 Python Bindings
 ===============
 
+.. warning::
+
+  To interact with Zeek, Broker's Python bindings should almost never be the
+  first choice nowadays. Consider them deprecated for most purposes. When setting
+  out to develop a new integration with Zeek, consider using :ref:`WebSockets <web-socket>`
+  instead. They are cross-platform, avoid pitfalls during deployment and upgrades
+  related to binary compatiblity. For debugging purposes, the WebSocket protocol
+  (in plaintext) is easier to introspect and monitor, too.
+
+
 Almost all functionality of Broker is also accessible through Python
 bindings. The Python API mostly mimics the C++ interface, but adds
 transparent conversion between Python values and Broker values. In the