Support for Multiple Peripherals per Extension - questions regarding implementation/pull request

Abierto
  • ¿Algo no está bien?
#663 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
javascript
Área
frontend, networking

Línea de trabajo

Comienza revisando los clientes ble.js y bt.js de scratch-vm mencionados, la vista scanning-step de scratch-gui y la restricción de sesión de Scratch Link. Antes de la implementación, obtén el acuerdo de los maintainers sobre el modelo de conexión, el flag de extensión, la API de runtime y el enfoque del modal; el trabajo estaría terminado con un diseño aprobado y acotado para la compatibilidad con múltiples periféricos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Goal

Allow Scratch extensions to discover, connect, and manage multiple peripherals simultaneously instead of limiting connections to a single device.

Motivation

I have multiple Lego WeDo 2.0 hubs (each providing 2 sensor/motor ports). While the official LEGO app allows connecting multiple hubs to one project, Scratch currently limits the extension to a single hub.

Proposed GUI changes
  • Device Connection Modal:
    • While the connection modal is open, Scratch continues discovering devices while displaying currently connected hubs.
    • Users can toggle connection states for individual hubs with a single click.
  • Dynamic Block Menus:
    • Once one or more hubs are connected and the modal is closed, the block dropdown menus dynamically update to display all available motors/sensors across all connected hubs (Plug & Play).
Proof of Concept

I have built a working prototype running on Linux. During development, several architectural questions arose. I would love to get feedback from the Scratch maintainers and community to align my implementation with Scratch's architectural goals for a future Pull Request.

Note on dynamic dropdowns: Scratch already supports dynamic block dropdown menus via callbacks, which works exceptionally well for runtime Plug & Play sensors/motors across hubs.

Technical Bottlenecks & Proposed Solutions
1. Session-Based Communication in ble.js / bt.js & Scratch Link

Currently:

  1. A single BLE/BT JSON-RPC session handles both discovery and connection for a single peripheral.
  2. Scratch Link constraint: WebSocket sessions handling discovery only allow connecting to devices discovered within that same session.

Proposed Solution:
Allow Scratch Link to connect to devices without requiring prior discovery in the exact same WebSocket session (connecting can fail gracefully regardless of this change).

  • Workflow: The client handles discovery in one WebSocket session, then opens separate sessions to manage connections to individual devices.
  • I verified this approach using an open-source Linux implementation of Scratch Link. Adapting Windows/macOS implementations should be doable.
  • bt.js / ble.js clients in scratch-vm would be updated to decouple discovery from connection management and handle multi-device sessions.
2. Extension Definition Flags

Extensions should be able to declare support for multiple devices:

  • Introduce an optional flag (e.g., allowMultiplePeripherals: true) in the peripheral extension configuration.
3. State Tracking in VM / Runtime

The runtime and peripheral management layer need a gateway to track active connections:

  • Proposed API methods: getConnectedPeripherals(extensionId) and setConnectedPeripherals(extensionId, deviceIds).
4. Device Connection Modal Updates

Because auto-connect (existing extension flag) is not suitable for multi-device workflows, we should build on top of the standard connection chooser dialog:

  • Option A: Extend the standard "scanning-step" view to support multi-selection and active connection toggling.
  • Option B: Introduce a dedicated scanning step component (e.g., scanning-step-multi).

What do you think of this?

Note: The initial prototype was developed with the assistance of an AI agent, and I have acquired a solid understanding of the relevant parts of scratch-vm, scratch-gui, and Scratch Link. Also this text was marked-up with help of AI :-) *

Lenguaje dominante
JavaScript
Estrellas
310
Forks
299
Merge medio
19 h 41 min
PR fusionados (30 d)
14

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de scratchfoundation/scratch-editor

Todos los issues de scratchfoundation/scratch-editor

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.