gecko-web-runtime-client 1.2.0__tar.gz → 1.3.1__tar.gz

{gecko_web_runtime_client-1.2.0/gecko_web_runtime_client.egg-info → gecko_web_runtime_client-1.3.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: gecko-web-runtime-client
-Version: 1.2.0
+Version: 1.3.1
 Summary: Thin Python client for the Firefox-derived WPR Gecko Worker protocol
 Author: WPR project
 License: MPL-2.0-compatible client; see the runtime bundle notices
@@ -11,6 +11,17 @@ Requires-Dist: loguru>=0.7.2; extra == "diagnostics"
 
 # Python client
 
+Version `1.3.1` pins runtime `155.0.6` with the native autonomous-navigation
+viewport repair. Upgrade the client, then run
+`python -m gecko_web_runtime install-runtime --version 155` to replace an older
+runtime in place. The Python workflow API and HTTP concurrency defaults are unchanged.
+
+Version `1.3.0` defaults to one Worker, 20 Channels,
+`ipc_backend="iocp"` and `release_mode="piggyback"`. Published version 1.2.0
+still defaults to one Channel, threaded IPC and immediate release. Runtime
+155.0.5 is required for the new defaults. Existing 1.2.0 installations keep
+their behavior until explicitly upgraded.
+
 The client provides a standard-library core plus an optional Loguru-backed
 diagnostics layer. From this directory:
 
@@ -66,16 +77,17 @@ helpers), `network/transport.py` (the versioned Worker boundary),
 
 `timeout` accepts seconds, `Timeout(total=seconds, pool=seconds)`, or `None`.
 `total` covers queueing plus the active request; `pool` can bound waiting for
-an available Worker slot. By default `max_workers=1`, so `asyncio.gather()` calls
-on one client queue behind one Worker. Set `max_workers=N` to let the same
-client instance dispatch up to N requests at once:
+an available request slot. The 1.3.0 default is one Worker with 20
+concurrent Channels. `asyncio.gather()` submits the work; the client limits
+active requests to `max_workers * max_channels_per_worker`. No arguments are
+needed to discover the installed runtime and enable the default transport:
 
 ```python
 import asyncio
 from gecko_web_runtime import AsyncWprHttpClient
 
 async def main():
-    async with AsyncWprHttpClient(max_workers=4, timeout=30) as client:
+    async with AsyncWprHttpClient() as client:
         responses = await asyncio.gather(
             *(client.get(f"https://example.com/api/{i}") for i in range(8))
         )
@@ -87,8 +99,8 @@ async def main():
 asyncio.run(main())
 ```
 
-This is a bounded Gecko Worker pool, not an HTTP socket-connection limit: the
-current named-pipe RPC accepts one in-flight request per Worker. Each extra
+Channels bound in-flight requests, not HTTP sockets or Python threads. Set
+`max_channels_per_worker` to change the single-Worker limit. Each extra
 Worker is a separate Firefox process/profile and therefore has its own Gecko
 CookieService state; multi-Worker cookie continuity is not shared or ordered.
 Keep the default `max_workers=1` when requests depend on a single browser cookie
@@ -96,12 +108,14 @@ jar or when minimizing memory is more important than parallel throughput. The
 pool grows lazily up to the configured cap and reuses Workers after requests.
 For latency-sensitive bursts, call `await client.warmup(url)` immediately after
 entering the client and before sending application requests. It starts the
-remaining Workers and makes one full GET per Worker to the supplied URL; the
+remaining Workers and makes one full GET per Channel slot to the supplied URL; the
 responses are read and released while the Worker connections stay open. This
 is real traffic, so use a safe, idempotent endpoint. Cookies set by that
-endpoint remain isolated in each Worker profile.
-An active client-side timeout or cancellation stops that Worker because the
-current protocol has no per-request cancellation; the next call replaces it.
+endpoint remain isolated in each Worker profile. With the new defaults a
+warmup call makes 20 real GETs; entering a client by itself makes none.
+Active timeout/cancellation in the default multiplexed mode cancels only its
+request Channel. Explicit legacy single-Channel mode stops the Worker and
+the next request replaces it.
 A queued request timeout leaves active requests and Workers untouched.
 Connect/read/write phase timeouts still need native Worker support.
 
@@ -127,8 +141,9 @@ completes. Set `WPR_RUNTIME_HOME`, `WPR_RUNTIME_DIR`, and
 
 Client 1.2.0 with runtime 155.0.5 supports `ipc_backend="iocp"` and
 `max_channels_per_worker=10` with `max_workers=1`, keeping one shared
-cookie/proxy session while issuing concurrent Necko requests. Defaults remain
-the independent-Worker threaded path. Older runtimes lack these capabilities;
+cookie/proxy session while issuing concurrent Necko requests. Version 1.2.0
+uses explicit opt-in; version 1.3.0 selects these features by default.
+Older runtimes lack these capabilities;
 upgrade both the client and runtime before enabling multi-Channel requests.
 See [selection, protocol, and reproducible build instructions](../source/gecko-net-worker/experiments/multiplex-network/README.md).
 
@@ -151,7 +166,8 @@ exact instantaneous maxima, or a claim of equivalent physical RAM consumption.
 See [results, limitations, and reproduction commands](tests/results/http-resource-comparison-20261011.md).
 The test entry points are `tests/integration/baidu_live_ab.py` and
 `tests/integration/baidu_resource_ab.py`. They remain development tests; the
-release keeps opt-in concurrency and transport defaults unchanged.
+measurements refer to the released 1.2.0 configuration, not a claim that
+the 1.3.0 defaults have identical resource costs.
 
 ## Network IPC diagnostics and pipe A/B
 
@@ -222,7 +238,7 @@ $env:WPR_PIPE_MODE = 'persistent'
 ```
 
 ```python
-async with AsyncWprHttpClient(max_workers=10, release_mode="piggyback") as client:
+async with AsyncWprHttpClient() as client:
     response = await client.get("http://127.0.0.1:8080/")
     body = await response.aread()
     await client.flush_releases()  # Optional explicit Worker-side confirmation.
@@ -236,7 +252,8 @@ pipe occupancy can delay it. Thresholds of 32 entries or 8 MiB trigger drains;
 they are not global caps on unread response memory. Only acknowledged entries
 are removed from the pending queue. Abort stops the Worker and discards its queue.
 
-The default remains `release_mode="immediate"`. Old Workers are rejected during
+The 1.3.0 default is `release_mode="piggyback"`; pass `"immediate"`
+explicitly to release each response through a separate RPC. Old Workers are rejected during
 capability negotiation if piggyback mode is requested, before any HTTP request
 is sent. `transport_stats` covers the currently resident pool, not retired Workers.