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

Aperta
  • Qualcosa non va?
#663 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
javascript
Ambito
frontend, networking

Direzione di ricerca

Inizia esaminando i client ble.js e bt.js di scratch-vm menzionati, la vista scanning-step di scratch-gui e il vincolo di sessione di Scratch Link. Prima dell’implementazione, ottieni l’accordo dei maintainer sul modello di connessione, sull’extension flag, sulla runtime API e sull’approccio del modal; il lavoro sarebbe completato con un design approvato e circoscritto per il supporto di più periferiche.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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 :-) *

Lingua principale
JavaScript
Stelle
310
Fork
299
Merge medio
19h 41m
PR unite (30g)
14

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di scratchfoundation/scratch-editor

Tutte le issue di scratchfoundation/scratch-editor

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.