Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Unify CClient/CServer as a single orchestration layer behind UI and JSON-RPC

Aberta
  • Algo errado?
#3,801 3 comentários 2 reações 0 responsáveis Ver no GitHub

@mcfnord já está trabalhando nisso.

Desde 19/7/2026.

  • #3806 de @mcfnord — aberto

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Refatoração
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
c
Domínio
api, backend-api-design, desktop

Direção de pesquisa

Comece rastreando CConnectDlg e CClientRpc em torno do exemplo do diretório atual e, em seguida, inspecione como CClient, CServer, CClientSettings e CServerSettings atualmente possuem ou expõem o estado. Migre incrementalmente um estado ou uma ação por vez, mantendo a funcionalidade existente funcionando; considera-se concluído quando a UI e JSON-RPC consumirem a mesma camada de orquestração, com paridade e sem lógica duplicada de ownership.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

feature request

Summary

Currently, Client and Server capabilities and states are scattered across UI and other classes rather than "owned" centrally.

This issue proposes refactoring so that CClient and CServer become the single source of truth for all state and actions, with both the Qt UI and the JSON-RPC interface acting as symmetric, parity consumers of that layer - nothing more.

(This came out of discussion on #3660 - and prior discussions - where a small RPC addition (getCurrentDirectory/getDirectories) surfaced duplicated logic between CConnectDlg and CClientRpc that should really live in one place.)

Goals

  • Clear separation of concerns between orchestration logic and presentation/control interfaces.
  • CClient and CServer as the orchestration core - the single arbiter of all Client/Server capabilities, state, and actions.
  • Full parity between UI and JSON-RPC. Anything the UI can do, JSON-RPC can do, and vice versa. No interface-specific logic duplicated across them. This should be sufficient, for example, to let someone write a local JSON-RPC + React (or any other) frontend that fully replaces the Qt UI.
  • CSettings / CClientSettings / CServerSettings encapsulated behind CClient and CServer, rather than read or mutated directly by UI or RPC code.

Proposed pattern

Using "current directory" as a worked example:

  1. CClient owns the state (e.g. current directory index) and exposes it via a canonical accessor.
  2. UI components (e.g. CConnectDlg) emit a signal on user interaction (e.g. "selection changed").
  3. CClient handles the signal and updates CClientSettings.
  4. CClientSettings emits its own change signal.
  5. Both the UI and CClientRpc listen and react independently — UI updates its display, RPC pushes new state to subscribers.

Neither the UI nor RPC owns logic the other doesn't have equal access to; both sit on top of the same CClient-owned state and signals.

Scope of JSON-RPC control

There is no remaining debate on how much should be controllable via JSON-RPC: full parity with the UI is the goal, including actions that affect other clients on a server (e.g. join/leave, mute). Restricting RPC to read-only, or to a subset of UI actions, would defeat the purpose — it would prevent RPC or other future mechanisms from being a viable full replacement for the UI.

Scope of exposure (local control)

Jamulus should continue to expose JSON-RPC only to the host machine itself. However, what the operator of that machine chooses to do with that local API - including running their own server-side bridge to expose a remote UI - is entirely outside Jamulus's domain and not something Jamulus needs to secure against. Jamulus's responsibility ends at the local socket; anything built on top (e.g. a remotely-accessible UI) is the hosting user's own responsibility.

Non-goals / explicitly out of scope for this issue

  • Ripping out CLI parsing and Settings persistence on the Server side (raised as a related but separate, larger job).
  • The longer-term "Jamulus as a DAW plugin" direction (bridges to Reaper/Audacity, etc.) — interesting, but a much bigger and more speculative rewrite than this issue is scoped for.

Whilst out of scope, it's hoped that the change in architecture will help towards both.

Why now

This is a foundational refactor that unblocks a class of feature requests (e.g. setCurrentDirectory, directory management setters) that keep surfacing in feature PRs and forcing the same "should this be centralized" conversation each time. Doing it once, centrally, avoids repeating this discussion piecemeal across future PRs.

Suggested approach

Incremental, in parallel with existing functionality — migrate one area of state/action at a time (starting with connection/directory handling, per the example above) into CClient/CServer ownership, with the existing UI and RPC code updated to consume it, rather than a big-bang rewrite. Keep the current implementation working throughout.

Linguagem predominante
C
Estrelas
1.1k
Forks
250
Merge médio
9d 18h
PRs com merge (30d)
4

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de jamulussoftware/jamulus

Todas as issues de jamulussoftware/jamulus

Issues semelhantes

Mais issues de C

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.