[Textlib] Újabb módosító javaslat

[Nagy Imre]

> Akkor itt tenném fel a kérdést az Infokernek, hogy TIOP-on nyert
> konzorciumból mennyi TextLibes könyvtárral lehet számolni? A
> konzorciumunk 8-at számlál...

És mind a 8 könyvtár textlib-es?

> modulokat, ráadásul ütemtervének megfelelően. A kérdés az, hogy a
> pályázati ütemterv átütemezhető vagy sem

Milyen határidők szerepelnek a nyertes pályázatokban?

>> Ne nézzük az email felszólítás esetét:
>> 1: Nem csak felszólítás kell, hanem lejárat előtti figyelmeztetés.
> Természetesen mind opcionálisan, ha akarom ;-)

Persze, ha az olvasó rekordjában a kérdéses mező üres (nincs pipa) akkor
nem kap..
Mcsere-vel pl: mindenkinél default-an át lehet állítani igen-re, és ahol
van mail cím az kap levelet.

>> 2: Lejárat előtt hány nappal kell kiküldeni a levelet? Olvasónként
>> különbőzőnek kell lennie.
> Vagy olvasói csoportonként?

Nemvagyok biztos benne hogy ez elég lenne. Szerintem érdemes lenne
olvasónként változtathatónak lenne.
Persze kell egy default érték szükséges, ami olv. kategárióhoz kell kötni.

>> 3: Email melett kell kapnia postai alapú levelet is? Olvasóként eltérő
>> lehet.
> Csoportonként, kategóriánként esetleg?

Hm..Pl: könyvtáros kategóriánál más a helyzet, és más a helyzet egy
gyermek kategóriával, akik még olvasni se tudnak.
De az email-t el lehet küldeni a szülőnek is. Szóval nem elég a csoport,
dönthet úgy az 5 éves gyerek apukája, hogy ő szeretne mail-t kapni.

>> 4: Mi van a rossz email címekkel? Visszapattanó levelek kérésköre..pl:
>> email alapján olvasó keresése. Mert jelenleg nem lehet.
> Arról nem is beszélve, hogy az MTA-k alap esetben 4 napig próbálják
> elküldeni, de figyelmeztetés jön vissza pár óránként.

Igen, ez MTA-ként változó, van ami nem küld semmit, csak a spoolba látszik
hogy van ami el se ment.
Ez kézi módszer lesz. Email feladója egy valós emailcímnek kell lennie.

>> 5: Ha nemkért postai levelet, akkor az utolsó (térités előtti) levél
>> mindenképp postán menjen ki? Vagy csak a könyv árát is tartalmazó levél
>> menjen ki postán?
> Az utolsó levél mindenképp postai, mivel ajánlottan kellene kiküldeni.

Szerintem elég ha a könyv árát (térítési díj megállapítása...) is
tartalmazó levél az ajánlott, térítéses.
(Fejből ha jól rémlik akkor az utolsó felszólítás postaköltsége is ugyan
annyi mint a többié, csak a térítéses levél árát lehet megnövelni. (pár
verzió óta)).

> Maga az e-mail-es kiküldés az MTA-k és maga az átviteli közeg miatt is
> bizonytalan. Amig az MTA-tól valaki át nem vette, addig nincs kézbesítve,
> márpedig ez alap esetben is több nap lehet. Hacsak nem használ saját
> MTA-t, ahol ez le van véve mondjuk 2 órára.
> Arról nem is beszélve, hogy ezeket vissza is kellene csatolni a TL-be.

Nemszeretném ha olyan funkciókat látna el a textlib ami alapvetően nem rá
tartozik. Ezt végezze az MTA. Ennek beállítása már a könyvtár feladata.

Visszacsatolni? Autmatikusan nem fogod megtenni. Jó persze lehetne valamit
készíteni rá, de fejlesztési időigénye, és az MTA különbőzősége miatt
szerintem nem érné meg.
Elég lesz egy mail fiók, és kézi levél átnézés, és tartalom alapján vagy
átírja a hibás mail címet, vagy kitörli.

De pl: mi van ha nem hibás az mail cím, csak megtelt? Indokolt lehet egy
funkció gomb: Levél ujraküldése...?

Ilyen hibák postai rendszer esetén is megvannak, csak van egy nagy
különbség a két rendszer közt: Email megoldás még mindig gyorsabb!
Hamarabb visszapattan a levél, mint ahogy a posta megfordul.

> Pedig jó lenne előbb megvitatni, mint a fejlesztés végén a teszt közben
> rájönni pár "apróságra".

Pl: email cím beírásakor és az összes módosításakor nem kellene egy teszt
levelet kiküldeni? Így a későbbi elírásokat el lehetne kerülni.

Vagy a @ utáni rész (pl. infoker.hu, listserv.niif.hu) létezését
ellenörizni email cím beírása, vagy módosítása után?

Email címet weben változtatni kell. Miért? Mert egyszerűen változhat.
Gyakrabban mint egy posta cím.
Ehhez mi kell? Mostani olvasói állapotnál biztonságosabb login. böngésző
vissza gombja..+titkositatlan jelszó (hash szükséges js oldalon)

De menjünk tovább: Olvasóként szerintem több mail címet is meg kell tudni
adni. Miért? Gyerek + szülő...Vagy apa, anya..

> Párszor említetted már a kistérségi rendszert, lehetne róla picit
> bővebben? Igény - vásárló kereslet - mutatkozik iránta?

Jészberényi konferencián nem voltál? Ott alaposan szóba került és mükődő
verziót is láttunk.

Igény van rá, elég sok. Mi már kb 1-2 hónapja szeretnénk használni. 11
kistérségi könyvtár lesz egy rendszerbe integrálva.
Röviden egy rendszerbe több kvázi független könyvtárat le fog kezelni.
Többféle leltárkönyvel.. Pl: lehet minden kistérségi könyvtárnak külön de
közös leltárkönyve.
De ennél jóval bonyolultabb a kistérségi rendszer. Annyira hogy teljes
mértékben én és szerintem más se látja át az egészet, hogy pontosan mit is
szeretnénk. használat közbe sokminden ki fog még derülni.

>> és mint az email felszólítás, webes előjegyzés, hosszabbítás időigényes.
>> Z39.50 szerverről nem is beszélve.
>
> Ez utóbbit érzem fajsújosnak, az e-mail is majdhogynem házilag
> összebarkácsolható: TL-től felhasználói azonosító alapján "alapadatok"
> lekérhetőek linux alól (van tervem a felhasználására). Átalakítani, hogy
> aktuális napi listát adjon vissza az e-mail-es felszólítandókról akár .csv
> formátumnak megfelelően, ezt már lehet(ne) kezelni bash-ből. A windows
> oldalról nem vagyok érintett ;-)

Én viszont a Z39.50 szervet fontosságát nagyon kicsire becsülöm. Miért van
rá szükség? hogy más könyvtár könnyedén tudjon HM adatokat letöleni a mi
rnedszerünkből?
Jelentkezzen valaki, akinél ez VALÓS igényként felmerült. Vagy bárhol
hátrányként jelentkezett.

Persze Email felszólítást maszek módon meg lehetne oldani.
DBF_LST segítségével bármit ki lehetne nyerni. Rakok mellé egy MYSQL
adatbázist + kis PHP admin felületet..

Mindent meg lehet oldani, de hosszútávon bukta!! Ss a textlib-es közösség
értékét se szolgálja.

Lassan áttérhetünk a webes könyvhosszabbítás és könyv előjegyzés kérdésére :)

Nagy Imre