ugrás a tartalomhoz

Media tartalom fallback

therest · 2013. Júl. 1. (H), 17.21
Helló!

Egy olyan rendszert szeretnék építeni ahol média tartalmak több verzióval rendelkezhetnek.
Amikor a kérés beérkezik a szerverhez (mondjuk http://valami.hu/ver1/kep1.png) akkor az adott fájl nem feltétlenül létezik a megadott útvonalon.
Van viszont két további mappa ver2 és ver3, amikben létezhet egy kep1.png nevű fájl és szeretném ezek közül kiszolgálni képet.

Lehetséges-e ilyen logikát építeni? Mivel lenne érdemes próbálkozni?

Előre is köszi!
 
1

Benned milyen ötletek

Hidvégi Gábor · 2013. Júl. 1. (H), 17.37
Benned milyen ötletek merültek fel?
2

Lehetséges

Poetro · 2013. Júl. 1. (H), 17.55
Igen, lehetséges ilyen logikát építeni. Csak megfelelő router kell hozzá. Apache HTTP esetén például mod_rewrite is használható erre.
3

Mivel nem vagyok birtokában a

therest · 2013. Júl. 2. (K), 12.10
Mivel nem vagyok birtokában a kellő rendszergazdai tapasztalatoknak, ezért routeres megoldások eszembe sem jutottak. De szívesen olvasnék a témában és utána már némi tudássalfelvértezve tudnám megkínálni a rendszergazdánkat a kérésekkel... :)
Ami miatt ez a megoldás kérdéses, hogy kellene valamiféle cache-t is csinálni, ne kelljen mindig ellenőrizni a fájlok meglétét. Illetve ha ez a cache könnyen újragenerálható/adminisztrálható lenne az sem lenne baj.
Továbbá a fallback nem mindig olyan egyértelmű, mert ezt leíró struktúrák (json fájlok) vezérlik, szerintem ilyesmit nem lehet egykönnyen a routerrel megetetni, bár ki tudja.

Gondoltam például arra is, hogy minden média kérés egy php szkripten keresztül megy, és az dobja vissza a tartalmat (header, mime, fileread stb). Persze itt is a htaccess-től indulnánk. Ha nincs meg a kért fájl akkor futtatjuk a szkriptet. Szerintem ez nagyon lassú lenne komolyabb terhelésnél. A sebesség pedig kritikus kérdés, mert egy nagyobb rendszerről van szó. Vagy csak én aggódom túl?

Gondoltam valami 3rd party média szerver-szolgáltatás használatára is, bár nem tudom ilyen fallback mechanikák vannak-e. A komolyabbak sok pénzt kérnek.

Végül felvetődött bennem, hogy magához az Apachehoz kéne hozzáírni egy modult, ami persze baromi nagy meló lehet - főleg teljesen laikusként nekiindulva - viszont ez biztosítaná a leginkább rendszer közeli, és nyilván leggyorsabb megoldást.
Értelem szerűen ilyenkor lenne egy webszerver sima apache-al a normál tartalmak kiszolgálására, meg egy másik moddolt amin minden más szükségtelen dolog ki van kapcsolva, és ez csinálná a kérdésben leírtakat. Ilyenkor a cache-t memóriában lehetne tartani, csak úgy mint a fallback mechanizmust leíró json configokat.
Valahol oda kéne beékelni a logikát, ahol a http-vel kapcsolatos dolgok mind lezajlódtak, a konkrét fájl olvasás következik.
4

Alkalmazás

Poetro · 2013. Júl. 2. (K), 12.21
Router alatt az alkalmazásodban levő router-t értettem, ami azt vezérli, hogy melyik folyamat vagy függvény aktivizálódjon az egyes kérések beérkezése esetén. Nem tudom, miben írod az alkalmazásodat, így bővebb tanácsot nem tudok adni ezügyben, de Node.js, és Java esetén például elég egyértelmű, hogyan kellene ezt megírni. Más nyelvek és rendszerek esetén sokkal bonyolultabb is lehet a megvalósítás.
PHP esetén például Klein.php router használatával és egy kis memcache bevezetésével is szépen le lehet zongorázni a problémát.
5

Ha a leiro strukturat is

vrnagy · 2013. Júl. 2. (K), 12.38
Ha a leiro strukturat is generalod, akkor onnan mar csak egy lepes a RewriteMap hasznalata Apache alatt. Ez lehet akar egy szoveges allomany, akar egy kulso program, ha a szoveges fajlt ki tudod generalni, akkor nem is kell a kepeknek eljutnia a PHP-ig.
6

Kösz a linkeket, elkezdek

therest · 2013. Júl. 2. (K), 12.53
Kösz a linkeket, elkezdek olvasni.

Php-ban készül, mivel ez az egész egy komplex branding/skining rendszer részeként kellene, ahol nem csak média tartalmak hanen a css-ek, js-ek, szöveges tartalmak is rendelkeznek fallback-el, ezeket pedig egy jól definiált mag vezérli.

Amit céloznék az az, hogy könnyen lehessen új brand-eket/skin-eket definiálni az egyes tartalmak redundáns tárolása nélkül. Tehát ha egy skin csak pár dologban tér el az alapértelmezett skin-től akkor csak az eltéréseket tároljuk. Ez pedig könnyebb adminisztrációhoz, átláthatóbb szerkezetekhez vezet reményeim szerint.