Spår 1
Varje uppdatering innehåller både klient och data. Videofilerna måste då bäddas in.

Spår 2
Klient + uppdateringar

1. Man tillhandahåller en klient en gång.
2. Content hostas på en publik server, alternativt ett intranät i form av ett ”paket” – ett eget filformat som binärt har bakat ihop alla filer till en enda. Paketet sparas på användarens dator och kan läsas offline av klienten.
3. Som ett extra skydd kan det vara möjligt att kryptera paketets data – jag har dock inte hittat någon information om detta ännu, men det vore konstigt om man inte skulle kunna det.

Spår 3
Som punkt 2, men med skillnaden att man använder sig av zip-filer med 128-bitars kryptering där nycken lagras i klienten. Har dock inte hittat att det skulle finnas något stöd för detta (dekrypteringen) men det känns inte omöjligt.

Spår 4
Klient + DRM-skyddade videofiler

1. Man tillhandahåller en klient en gång.
2. Content hostas på intranätet/portalen i form av en xml-fil och DRM-skyddade videofiler (*.mp4 eller *.flv) som laddas ner och sparas på användarens lokala disk. DRM-skyddet hindrar obehöriga att spela upp filen då skyddet kräver att man anger användarnamn och lösenord (som man nog skulle kunna automatisera inne i klienten så att den bara spelas upp där direkt).

Jag är en smula osäker på hur förfarandet i punkt 4 riktigt fungerar, att det går vet jag, men jag vet i detta läget inte om det är optimalt eller om det finns några andra nackdelar som man måste ta med i beräkningen.

Det sista spåret känns som det som är mest intressant, men jag har aldrig jobbat med DRM-skyddet och vet därför inget om det.