Skip to content

Retire when.js and use async iterators/streams for progressive calls #596

Description

@oberstet

Summary

Replace the unmaintained when.js library with modern JavaScript patterns (async iterators/streams) for progressive call results.

Background

Currently, AutobahnJS uses when.js for:

  • Full Promises/A+ compliance
  • Deferreds (deferred.resolve/reject/notify)
  • Progress notifications via deferred.notify()

Progressive call results in WAMP rely on the notify() mechanism, which native Promises don't support.

Current State (v26.1.1)

For release 26.1.1, we're keeping when.js@3.7.8 (the final stable release) to:

  • Avoid API breaking changes
  • Minimize risk for existing users
  • Maintain backward compatibility

Proposed Solution

Replace when.js with async iterators/streams for progressive results:

// Modern async iterator pattern
for await (const chunk of session.callStream("com.example.longop", [args])) {
    console.log("interim result:", chunk);
}
console.log("call completed");

This aligns with modern JavaScript best practices and provides:

  • Native browser/Node.js support
  • No external dependencies
  • Better memory efficiency for streaming results
  • Cleaner async/await syntax

API Design Options

Option A: Clean Break (Recommended)

Replace the current .progress() callback pattern entirely with async iterators:

// Old pattern (deprecated)
session.call("proc", [args], {}, {
    onProgress: (chunk) => console.log(chunk)
});

// New pattern
for await (const chunk of session.callStream("proc", [args])) {
    console.log(chunk);
}

Option B: Dual API (Transitional)

Offer both patterns during transition:

  • session.call() - returns Promise, supports optional onProgress callback
  • session.callStream() - returns async iterator

Then deprecate the callback pattern in a future release.

Implementation Notes

  • This is a breaking API change for users relying on progressive results
  • Requires documentation updates
  • Requires migration guide for existing users
  • Consider: Is backward compatibility worth the maintenance burden?

Target

  • v26.2.1 or later

References

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions