Something I'd like to add on. Some recent changes made the default serializer plain JSON with the expectation that request interceptors will be used for custom request serialization. With this, there are some inconsistencies and misleading wording about what gets set for a "serializer" option. I think we should also rename all of these options in the GLVs like serializer (in Java), reader (in JavaScript) to "responseSerializer" to match the other two GLVs. "responseSerializer" more accurately describes what this option actually sets now.
On Tue, Jun 23, 2026 at 3:23 PM Guian Gumpac via dev < [email protected]> wrote: > Following up on the connection-option standardization, a few naming/unit > decisions to confirm across all five GLVs: > > 1. batchSize (all GLVs): the connection-level defaultBatchSize becomes > batchSize (default 64). It's the connection-level default that fills a > request's per-request batchSize when unset. Re-cased per language idiom > (Java/JS batchSize, Go/.NET BatchSize, Python batch_size). > 2. Timeouts get both a duration-type setter and a millis setter (all GLVs > except JS): each timeout (connectTimeout, idleTimeout, readTimeout, > keepAliveTime) is settable two ways: > - a duration-type form under the canonical name, using each language's > idiomatic duration type: Java java.time.Duration, Go time.Duration, .NET > TimeSpan, Python datetime.timedelta. > - an explicit-milliseconds form with a Millis/_millis suffix > (connectTimeoutMillis, connect_timeout_millis, etc.) for callers who prefer > a raw number. Config-file keys use the millis-suffixed names since a config > value is a bare number. > > 3. JS is the exception: JavaScript has no standard duration type, so JS > keeps a single millisecond number option under the canonical name > (connectTimeoutMillis, etc.), no duration twin. > > Thanks, > Guian > >
