Skip to content

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

@oberstet

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 [email protected] (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

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions