Content delivery architecture defines how digital signage content moves from creation (CMS) to display (player). The two fundamental models are push (CMS sends content to players) and pull (players fetch content from a source). SpinetiX supports both: Elementi uses push delivery over HTTP, Arya uses pull delivery from cloud storage, and WebDAV enables automated pull from network shares. All models include local caching — content plays independently of network availability after initial delivery.
Delivery Models
Push Delivery (Elementi)
The designer clicks "Publish" in Elementi, and content transfers directly to the target player(s) over HTTP. Elementi connects to each player's web interface and uploads files. This is immediate and explicit — the designer controls exactly when content goes live.
- Pros: Immediate, deterministic, simple to understand
- Cons: Requires direct network path to each player, doesn't scale beyond ~50 players per publish
- Best for: Small-to-medium deployments, staging environments, testing
Pull Delivery (Arya Cloud)
Content is uploaded to Arya cloud. Players poll the cloud for updates at configurable intervals. When new content is available, the player downloads it. This decouples the CMS from individual players — publish once, all assigned players pull automatically.
- Pros: Scales to thousands of players, works across WAN/internet, supports geographic distribution
- Cons: Not instant (polling interval delay), requires internet connectivity
- Best for: Multi-site deployments, large fleets, geographically distributed installations
Pull Delivery (WebDAV / Network Share)
Players pull content from a WebDAV server or mapped network share. Content is placed in a folder, players sync from that folder. This enables automated pipelines — scripts generate content, place it in the share, players pick it up. No CMS interaction needed.
- Pros: Fully automatable, integrates with CI/CD pipelines, self-hosted
- Cons: Requires WebDAV infrastructure, no built-in content preview
- Best for: Automated content workflows, data-driven deployments, enterprise integration
Delta Sync and Efficiency
SpinetiX players use delta sync — only changed files transfer during updates. A 50 MB project with a 200 KB price change transfers only the changed data file (200 KB), not the entire project. This drastically reduces bandwidth consumption and update time, especially for large media-rich projects deployed over WAN connections.
Delivery Architecture Comparison
| Model | Direction | Latency | Scale | Network Requirement |
|---|---|---|---|---|
| Elementi Push | CMS → Player | Instant | ~50 players | LAN / direct IP |
| Arya Pull | Player → Cloud | Polling interval | Unlimited | Internet |
| WebDAV Pull | Player → Server | Polling interval | Hundreds | LAN / WAN |
| USB Sneakernet | Physical media | Manual | Any | None (air-gapped) |
Key Parameters
| Parameter | Value | Why It Matters |
|---|---|---|
| Delta sync | Changed files only | Minimal bandwidth for updates |
| Local cache | Complete project on player | Offline playback guaranteed |
| Transfer protocol | HTTP/HTTPS | Works through standard firewalls |
| Encryption | TLS 1.2+ | Secure content in transit |
| Retry | Automatic on failure | No manual intervention needed |
Common Mistakes
- Full project re-upload for small changes. Without delta sync awareness, some workflows re-upload entire projects for a single price change. Use SpinetiX's built-in incremental sync — it automatically detects and transfers only changed files.
- No offline fallback planning. If your architecture assumes always-on connectivity, a network outage means blank screens. SpinetiX's local cache prevents this, but you must design content that degrades gracefully (e.g., cached data with "last updated" timestamps).
- Push delivery over WAN. Pushing content from Elementi over slow WAN links to 50 remote sites is painful. Use Arya pull delivery for geographically distributed deployments — upload once, players pull independently.
- Unencrypted delivery. Content crossing networks without TLS can be intercepted or modified. Always use HTTPS for content delivery, especially over public networks and VPNs.