Skip to content

README.md

Latest commit

 

History

History
75 lines (56 loc) · 3.81 KB

README.md

File metadata and controls

75 lines (56 loc) · 3.81 KB
Raw
type Package Documentation
title CorePlay service — operations, commands, the core-play binary
description The Service facade (list, verify, prepare-play, plan/render/write bundle), Core command registration, and the standalone core-play binary with its launch flow
repo core/play
module dappco.re/go/play

Service — operations, commands, the core-play binary

The shell-agnostic operations layer and its two frontends. Source: go/service.go, go/command.go, go/cmd/core-play/.

Service

service := play.NewService(os.DirFS(root), nil) // nil = package-level engine registry
Method Input Output
ListBundles ListRequest{Root, JSON} []BundleSummary
VerifyBundle VerifyRequest{BundlePath} VerifyResult
PreparePlay PlayRequest{BundlePath} PlayPlan (bundle + resolved engine + launch plan + issues)
PlanBundle BundleRequest BundlePlan, ValidationErrors
RenderBundle BundleRequest RenderedBundle (nothing written)
WriteBundle BundleRequest, BundleWriter materialised bundle

BundleRequest carries everything play/bundle accepts: identity fields (name, title, author, year, platform, genre, licence), engine + profile + binary (path/data/sha256), artefact (path/data/sha256/size/media type/source), acceleration and filter, resource limits, distribution mode and BYOROM, entrypoint, config/chain/SBOM paths, and save/screenshot paths.

Core command registration

play.Register(c *core.Core) installs the command set; handlers parse core.Options into the request DTOs:

Command Description Result value
play Run preserved software in a STIM bundle PlayRequest
play/list List available STIM bundles ListRequest
play/verify, play/shield-verify Verify Shield surfaces without running VerifyRequest
play/bundle Create a STIM bundle from artefact BundleRequest
play/engines List available runtime engines engine names

The core-play binary

go/cmd/core-play/main.go creates a Core (core.New(core.WithOption("name", "core-play"))), registers the commands, and parses argv into operations: launch (default), list, verify, shield-verify, info, bundle, engines. play <sub> aliases work too.

core-play                       # launch bundle in cwd
core-play mega-lo-mania         # launch by directory name
core-play list --root games/ --json
core-play verify mega-lo-mania
core-play bundle -name demo -rom rom/demo.zip -platform dos -engine dosbox -archive

bundle flags: -name and -rom are required; -root, -title, -author, -year, -platform, -genre, -licence (default freeware), -engine, -engine-binary, -profile, -source, -cpu-percent, -memory-bytes, -byorom, -archive (write the deterministic zip).

Environment: CORE_PLAY_ROOT overrides the bundle root; CORE_PLAY_HOME overrides the sandbox home (default os.UserHomeDir()).

Launch flow

runLaunch chains the whole pipeline:

  1. Service.PreparePlay — load bundle, resolve engine, get launch plan; validation issues abort.
  2. PrepareSandbox — create ~/.core/play/<name>/ layout.
  3. SandboxPolicy.ValidateLaunch(plan) — reject plans that widen the policy.
  4. engine.Run(entrypoint, EngineConfig{...}) — execute through Core's process primitive, output streamed to stdout.

File map

File Contents
go/service.go Service, VerifyResult, PlayPlan, BundlePlan, operations
go/command.go Command names, Register, request DTOs, option parsing
go/cmd/core-play/main.go Operation parsing, launch flow, env handling
go/cmd/core-play/bundle.go Bundle operation wiring
go/cmd/core-play/report.go List/verify/info output