TODO/Nápady a postřehy na rozšíření nebo úpravy existujících funkcí systému
Z VirtlabWiki
< TODO(Rozdíly mezi verzemi)
| Verze z 12:44, 27. 3. 2008 Gry72 (Diskuse | příspěvky) ← Předchozí porovnání |
Aktuální verze Gry72 (Diskuse | příspěvky) |
||
| Řádka 5: | Řádka 5: | ||
| * Představme si uživatele, který chce spustit nějakou konfiguraci řekněme ve 21 hodin. Systém zjistí, že ve 21 hodin nelze vyhovět jeho požadavkům a odmítne ho. Jak nákladné by bylo zjistit nejbližší termín, ve kterém již lze uživateli vyhovět a k odmítnutí připsat např. "'''V požadovaném termínu Vám nelze vyhovět. Nejbližší další termín pro tuto konfiguraci je 21:15 (tj. o 15 minut později). Přejete si posunout Vaši původní rezervaci na nový termín?''' | * Představme si uživatele, který chce spustit nějakou konfiguraci řekněme ve 21 hodin. Systém zjistí, že ve 21 hodin nelze vyhovět jeho požadavkům a odmítne ho. Jak nákladné by bylo zjistit nejbližší termín, ve kterém již lze uživateli vyhovět a k odmítnutí připsat např. "'''V požadovaném termínu Vám nelze vyhovět. Nejbližší další termín pro tuto konfiguraci je 21:15 (tj. o 15 minut později). Přejete si posunout Vaši původní rezervaci na nový termín?''' | ||
| ** Protože je informace o obsazenosti prvků distribuována a mapovací algoritmus centralizovaný, muselo by se řešit asi zkusmo - pokusit se o rezervaci po hodině, dvou, zítra ve stejný čas atd. (rezervaci ale neCOMMITovat) | ** Protože je informace o obsazenosti prvků distribuována a mapovací algoritmus centralizovaný, muselo by se řešit asi zkusmo - pokusit se o rezervaci po hodině, dvou, zítra ve stejný čas atd. (rezervaci ale neCOMMITovat) | ||
| + | |||
| + | * "Kaskadni: mazani ulohy (vsechny soubory, s testem, zda nejaky soubor neni pouzit i nekde jinde). | ||
Aktuální verze
- Možnost prodloužení probíhající rezervace, pokud je použité vybavení v nasledujícím časovém období volné. Stejně tak zkrácení (do současného okamžiku).
- při prodloužení by se otestovalo, jestli je použité zařízení volné a pouze by se v CRONU posunul čas deaktivace a v databazi příslušných rezervačních serverů (a možná i řídící aplikace, pokud si eviduje] by se změnil čas konce rezervace
- Implementuje Katka
- Představme si uživatele, který chce spustit nějakou konfiguraci řekněme ve 21 hodin. Systém zjistí, že ve 21 hodin nelze vyhovět jeho požadavkům a odmítne ho. Jak nákladné by bylo zjistit nejbližší termín, ve kterém již lze uživateli vyhovět a k odmítnutí připsat např. "V požadovaném termínu Vám nelze vyhovět. Nejbližší další termín pro tuto konfiguraci je 21:15 (tj. o 15 minut později). Přejete si posunout Vaši původní rezervaci na nový termín?
- Protože je informace o obsazenosti prvků distribuována a mapovací algoritmus centralizovaný, muselo by se řešit asi zkusmo - pokusit se o rezervaci po hodině, dvou, zítra ve stejný čas atd. (rezervaci ale neCOMMITovat)
- "Kaskadni: mazani ulohy (vsechny soubory, s testem, zda nejaky soubor neni pouzit i nekde jinde).
