Pmk2 Paella Player Bundle Laravel Package

Technical Evaluation

Architecture fit: Poor for a Laravel application. teltek/pmk2-paella-player-bundle is a Symfony bundle built for Pumukit, not a Laravel package. It likely depends on Symfony service container conventions, Twig templates, routing, Pumukit domain models, and Paella Player assets/configuration. Laravel’s service container, routing, Blade, and package discovery do not map to Symfony bundles. Direct adoption would require a Symfony bridge or a separate Symfony/Pumukit runtime, which is disproportionate for a video player integration.

Integration feasibility: Low as a Composer dependency. The only credible leverage is as a reference implementation or as a source of Paella player assets/configuration patterns. A Laravel team should integrate Paella directly through front-end assets (Vite/npm or copied static files) and Laravel-owned playback endpoints, rather than pulling in a Pumukit-specific Symfony bundle. If Pumukit APIs are mandatory, isolate them behind a sidecar service and expose a narrow playback contract to Laravel.

Technical risk: High. The package has 1 star, 0 dependents, and a last release dated 2019-03-20, indicating negligible community adoption and no active maintenance. It likely targets older PHP/Symfony versions, creating Composer conflict and security-patching risk. The bundled Paella version may be outdated versus current Paella/paella-core releases, with unknown browser, codec, subtitle, DRM, and accessibility behavior. Licensing and transitive dependency posture should be verified before any reuse.

Key questions:

• What exactly do we need: a Paella player embed, Pumukit CMS integration, or both?
• Which Paella Player version and feature set are required (HLS/DASH, subtitles, annotations, live, DRM, analytics)?
• Is the bundle’s value in player assets, configuration, or Pumukit-specific server routes?
• What PHP/Symfony versions does it require, and can those coexist with our Laravel runtime?
• What is the license and security status of the bundle and its transitive dependencies?
• Can we satisfy playback auth, signed URLs, CORS, and token refresh entirely in Laravel?
• Is there a maintained Paella wrapper or should we build a thin Laravel/Vite integration?

TPM recommendation: Do not adopt as a runtime dependency. Treat it as a short-lived reference spike only; budget for a direct Paella integration or a maintained alternative.

Integration Approach

Stack fit: Weak. Laravel + Symfony bundle is a cross-framework mismatch. The viable Laravel path is to consume Paella as front-end JavaScript/CSS and expose Laravel APIs for playback manifests, captions, and authorization. The bundle’s Symfony routes, Twig helpers, and Pumukit services should not enter the Laravel codebase.

Migration path:

1. Run a time-boxed discovery spike to inventory the bundle’s Paella assets, config schema, and Pumukit coupling.
2. Extract only static player assets and configuration examples if licensing permits; otherwise use upstream Paella.
3. Build a Laravel-native player wrapper: Blade/Inertia/Livewire component, Vite asset pipeline, playback token endpoint, and media URL policy.
4. Map old bundle configuration to Laravel config and environment variables.
5. Replace any Pumukit-specific metadata calls with Laravel services or a thin sidecar API.
6. Cut over behind a feature flag and retain a fallback player during rollout.

Compatibility: Expect incompatibility with modern Laravel (PHP 8.1+/8.2+) and current Symfony. The 2019 release predates many current Paella APIs and PHP/Symfony support matrices. Validate Composer resolution in an isolated branch only; do not attempt to install it into the main Laravel application without a dependency-conflict review.

Sequencing: Decide “reference vs dependency” first. If reference, proceed to asset extraction and a standalone Paella proof of concept. If dependency, require a Symfony/Pumukit sidecar architecture rather than in-process Laravel integration. Complete security/license review before building UI. Then implement Laravel playback APIs, player component, observability, and a rollback path. Avoid parallel work on Pumukit integration until the Paella-only proof of concept proves playback, auth, and captions.

Operational Impact

Maintenance: Effectively orphaned. With one star, zero dependents, and no release since 2019, there is no credible upstream support channel. Any fork becomes our maintenance burden, including Paella upgrades, security patches, and PHP/Symfony compatibility. A Laravel-owned thin wrapper around maintained Paella assets is materially cheaper to operate.

Support: Community support is negligible. Troubleshooting will rely on source inspection and Paella upstream documentation, not bundle maintainers. Internal ownership must be explicit: front-end player owner, media API owner, and security owner.

Scaling: Static player assets scale well via CDN, but the bundle’s server-side Symfony routes do not fit Laravel scaling patterns. Playback scaling depends on manifest delivery, token issuance, CDN, and origin capacity, not this package. Avoid making the player bundle a stateful service.

Failure modes: Composer dependency conflicts; Symfony/Laravel route and container collisions; outdated Paella assets failing on modern browsers or codecs; CORS/token/auth mismatches; caption and manifest URL breakage; abandoned dependencies with security exposure; configuration drift between Pumukit-era examples and Laravel runtime; and no upstream fixes during incident response.

Ramp-up: Moderate for Paella front-end integration, high for the Symfony/Pumukit bundle internals. Engineers will spend time reverse-engineering legacy conventions rather than delivering product value. Plan a short spike, not a broad training investment. Operationally, instrument player startup errors, manifest failures, rebuffer rates, and token failures from day one; keep the integration behind a feature flag and document a rollback to the existing player.