Trimmelés

2026-01-12T00:00:00+00:00

Az elmúlt hetekben a szerver stabilitásával küzdöttünk. Ahogy korábban írtuk, a kritikus, erőforrás-igényes és nyilvánosan elérhető feladatok hosszú ideje az idővonalak generálása (és így a bonyolult keresési lekérdezések) valamint a nagy fájlok feldolgozását vagy generálását érintő feladatok voltak; nevezetesen az IIIF API és a PDF-generálás.

A legutóbbi bejegyzésben részleteztem, hogyan korlátoztuk jelentősen a nyilvános PDF-generálási funkciók elérhetőségét a museum-digital rendszerben a rendelkezésre álló erőforrások szerint. Ez azonban, mint kiderült, nem volt elegendő a rendszereink megbízható stabilitásának biztosításához. Miután a szerver ismét leállt december 26-án, az IIIF Image API-t ugyanabba a PHP-környezetbe helyeztük, amit a PDF-generálás is használ – ez azt jelenti, hogy bármely felhasználó/IP csak 10 lekérést hajthat végre percenként, és bármely museum-digital példánynál csak egy PHP worker szolgálja ki azt. Ez lehetővé tette, hogy a frontend többi részén a maximálisan elérhető erőforrásokat jelentősen csökkentsük. (Két eseten kívül, ahol az IIIF Image API akár 80 MB RAM-ot is használhat és a frontend más része nem haladja meg az 5 MB-ot). Azóta a rendszer úgy fut, mintha az AI scrapelés soha nem lett volna probléma.

Korlátozott búcsú az IIIF-től és a szerveroldali képmanipulációtól

Mit jelent ez a gyakorlatban? Egyrészt nem távolítottuk el teljesen az IIIF kép API-t. Minden általa generált link érvényes marad és továbbra is kiszolgálásra kerül, még ha viszonylag lassan is.

Másrészt a felhasználói élmény az IIIF-nézőben való képböngészéskor jelentősen romlik, bár ez nagymértékben függ az adott IIIF-nézőtől. A legnépszerűbb „teljes” IIIF-nézők a Mirador és a Universal Viewer. Jelentős problémák (vagy a tárgy képeinek teljes használhatatlansága) várhatók a Mirador esetében. A Mirador alapbeállításban a képet több szegmensre bontva tölti be, majd ezekből állítja össze a megjelenített képet. A szegmensek létrehozása a szerveren történik, így erőforrást igényel központilag. Emellett rendkívül alacsony határidőket szab a válaszidőkre, amit a museum-digital IIIF Image API-ja most rendszeresen túllép az agresszív lekéréskorlátozás miatt. Ha csak az Universal Viewer demó telepítését nézzük, a szoftver sokkal célzottabban hívja az API-t, és a korlátozások ellenére még jól működhet.

Amennyire tudom, nincsenek publikált adatok az egyes IIIF-nézők piaci részesedéséről, illetve arról, hogy a API-tól független IIIF-nézőket valójában mennyire használják rendszeresen. A legszkeptikusabb – és valószínűleg helytálló – feltételezés az lenne, hogy azoknak a felhasználóknak az aránya, akik IIIF-et használnak API-mellett nem hosztolt nézővel, elhanyagolható, és a legtöbben a fent említett nézők egyikét használják. Tapasztalatunk ismét alátámasztja ezt: 2020-ban adtuk ki az IIIF 2 implementációnkat, de lényegében senki sem vette észre, amíg nem kezdtünk IIIF-nézőt is hosztolni.

Mivel a Miradort használjuk nézőként, feltételezhetjük, hogy a museum-digital „látható” IIIF kép API-ja többé-kevésbé nem működik megfelelően. Azok a fejlesztők, akik közvetlenül használják az API-t Mirador telepítése nélkül, még mindig profitálhatnak az API-ból. De ezek viszonylag kevesen vannak.

Az IIIF Image API számára biztosított erőforrások radikális korlátozása így valószínűleg egy búcsút jelent az IIIF-től, korlátozott formában. Az alapötlet nagyszerű: egységes módon hivatkozni egy kép részeire (vagy később egy szélesebb médiafájlra) és annotálni azt. A megnövekedett botaktivitás, a csökkenő források és a várhatóan növekvő hosztingköltségek idején a mi példánk korai jelzés lehet arra, hogy az API-t a szolgáltatók által implementált módon meghatározó döntés korlátozza az IIIF teljes támogatásának lehetőségét a jól felszerelt intézményekre. És ahogy a források csökkennek, egyre kevesebb intézményre jut. Reméljük, hogy az IIIF által kívánt alapvető cél más módon is elérhető lesz a jövőben; oly módon, ami bárki számára hozzáférhető. Reálisan ez azt jelenti, hogy a számításnak a kliensgépeken kell történnie, nem a szerveren.

Hogy a történet pozitívan záruljon: mióta korlátoztuk az IIIF Image API-t, rendszereink újra kiválóan futnak, és lehetővé vált a museum-digital portáljainak további lekéréskorlátozásainak csökkentése. Figyelni fogjuk a helyzetet, és fokozatosan növeljük a limiteket, hogy több egyidejű API-lekérés engedélyezett legyen anélkül, hogy a stabilitást veszélyeztetnénk.

Kommunikáció

Másodsorban az egész ügy kihívást jelentett a kommunikációs csatornáink számára. Ha bárhol jelentős hiba történik a museum-digital rendszerben, én személyesen titkosított hibaüzenetet kapok e-mailben. Általában. Ebben az esetben a fő komponens, ami leállt, a PHP-szerver volt, amely a levelek küldéséért is felelős. Ha egy szolgáltatás leállt, az elsődleges módja a hibáról való értesülésnek az volt, hogy erről kaptunk e-maileket. Így a reakcióidők rosszabbak voltak, mint kellett volna. Ez azt jelenti, hogy javítanunk kell a monitorozást.

Másrészt az is problémát jelentett, hogy elmagyarázzuk, mi történik. Volt egy fórumtémánk a fórumon, amit kevesen olvastak. Voltak a blogbejegyzések, amelyeket szintén kevesen olvastak. Hiányzik (vagy hiányzott) egy egységes információforrás a jelenlegi eseményekről, amit feltételezhetően mindenki olvasna. A blog pontosan ezt a célt szolgálhatná és kellene, hogy szolgálja.

A musdb bejelentkező képernyőjének jobb felső sarkában évek óta a régió legutóbbi két blogbejegyzését, valamint a blog „fejlesztés” kategóriájának legfrissebb bejegyzéseit mutatjuk. Ezután alapértelmezetté tettük a „maradjak bejelentkezve” funkciót, ami azt jelenti, hogy az emberek már nagyon ritkán látják a bejelentkező oldalt.

A legtöbb felhasználó első oldala bejelentkezéskor vagy musdb megnyitásakor a “főoldal”, amelynek alapértelmezett aloldala korábban összefoglalót nyújtott a felhasználó által elérhető adatbázis-tartalomról, egy csempét a személyes jegyzetekhez, egy csempét a régió adminisztrátorainak üzeneteivel, egy csempét a Discourse fórum integrációjához, valamint linkeket a múzeum webes megjelenéséhez.

Az adatbázis-tartalom összefoglalója és a múzeum linkjei mindenképp hasznosak. A többi funkció kevésbé. Az aktuális használat ellenőrzése azt mutatta, hogy szinte senki nem használta a jegyzetfunkciókat (valószínűleg azért is, mert a musdb máshol jobb alternatívát kínál), míg a Discourse integráció évek óta nem volt használatban. Így a musdb elsődleges funkciói nagyrészt kihasználatlanok maradtak, miközben helyet foglaltak, amely a releváns blogbejegyzésekhez tartozó feed számára hasznosítható lett volna.

Ezért eltávolítottuk a használaton kívüli funkciókat, és helyettük egy esztétikailag tetszetősebb feedet helyeztünk el. Ez a feed most tartalmazza a felhasználó nyelvén a fejlesztési feed két legújabb blogbejegyzését, a regionális vagy nemzeti feedet (szintén a felhasználó nyelvén), valamint – ami fontos – az angol nyelvű fejlesztési feedet. A legfrissebb fejlesztéssel kapcsolatos bejegyzések egyikét sem fordítottuk le más nyelvre, főként azért, mert az időt inkább a problémák enyhítésére vagy javítására fordítottuk, nem pedig újabb nyelven történő leírására. Ráadásul a legtöbb felhasználó elég angoltudással rendelkezik a bejegyzések megértéséhez. Azok számára pedig, akik nem: a közösségi hozzájárulások – beleértve a fordításokat is – mindig szívesen látottak.

A musdb főoldal most tartalmaz egy feedet, amely a museum-digital fejlesztésével kapcsolatos és a régióban történő eseményekről szóló legfrissebb híreket mutatja. A bejegyzések kronologikus sorrendben jelennek meg.

info

AI Use

(Post image generated using Z-Image)

info

License

Ez a tartalom a Creative Commons Attribution 4.0 Nemzetközi licenc alatt érhető el.

Verziókezelés és Tömeges adatátvitel

2025-02-10T00:00:00+00:00

A 2025-ös év eddig két új funkciót hozott a MúzeumDigitárban: a tárgyadatok részletes verziókezelését és egy új tömeges változtatást, amely lehetőséget nyújt, hogy tömegesen át lehessen vinni tárgyadatokat egyik szabad szöveges mezőből a másikba.

Verziókezelés

A MúzeumDigitár egyik fájóan hiányzó funkciója a részletes verziótörténet volt a rekordok esetében. A verziókezelés lehetővé teszi az adatok visszakövetését vagy visszaállítását egy elrontott tömeges feldolgozási kísérlet vagy egy mező tartalom véletlen törlése után.

Mostantól egy tárgyrekord összes korábbi verziója megtekinthető a “Rekord történet” fülön. A felületen egy új „Verziókezelés” (jelenleg: Open Versioning, fordítás hamarosan) gomb jelenik meg a fül tetején.

A gombra kattintva egy felugró ablak nyílik meg, amely táblázatos formában jeleníti meg a különböző verziókat. A tárgy különböző adatai külön füleken érhető el és ezáltal külön táblázatokra vannak bontva, például Alapadatok, Esemény, Kulcsszó stb.

A verziótörténet egy táblázatos nézetben jelenik meg a felugró ablakban. Azok a cellák, amelyek értéke az adott verzióban megváltozott az előzőhöz képest, szaggatott vonallal vannak kiemelve.

Tömeges adatátvitel

Egy másik gyakran kért funkció – különösen importálás után – az a lehetőség, hogy egy tárgy egyik adatmezőjének tartalmát át lehessen vinni egy másikba.

Mint minden más „Tömeges változtatás” a tömeges átvitel is egy keresés találataira vonatkozik. A funkció elérhető a Tárgy menüpont oldalsávjából, miután egy keresést végrehajtottunk.

Keresés után az oldalsáv alsó részében különböző exportálási és tömeges lehetőségek jelennek meg. A lista legalsó részén található az új „Adatátvitel” (jelenleg: Batch transfer, fordítás hamarosan) opció.

Képernyőkép az új lehetőségről, amely lehetővé teszi a tárgy adatok tömeges átvitelét egyik szabad szöveges mezőből a másikba.

A szabad szöveges mezők mellett két „speciális forrás” is választható a Kiegészítő fülről. A „részletes méretadatok” és a szeparált „anyag“ és „technika“ mezők. Az adatmezők közötti átvitel során a célmező tartalma felülírható a forrásmező tartalmával, vagy a forrásmező tartalma elé vagy mögé fűzhető.

Az adatátvitel a musdb API-ján keresztül is használható. Ehhez egy új API útvonal került bevezetésre: /object/transfer_by_search/{mode}.

tip

tip

This content is licensed under a Creative Commons Attribution 4.0 International license.

museum-digital:blog - Technik/Design