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

[Szabo Istvan]

> > 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?

Igen, illetve talán 2 nem de azok meg azok lesznek.


> > 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?

Az egyes tagok ütemezésétől függ, mindenki saját magának ütemezte a
jelenlegi felkészültségi fokának megfelelően. A végén jut mindenki 1
szintre. Így lehet, hogy valakinek a II. negyedévben van a megvalósítási
határidő, nálunk speciel a III. negyedév.


> >> 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.

Igen, erre gondoltam, hogy olv. kat. szerint lenne, de magasabb prioritást
élvez, ha az olvasó erről nyilatkozik.


> >> 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.

Ok, de az apuka jelen esetben a jótálló, azaz ott lehetne megadni.


> >> 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.

A feladónak mindenképp valósnak kell lenni, mint ahogy a papír postán is
valós (esetleg alias, de ez részletkérdés).
A kézi módszert ahol lehet kerülöm, nem csak kényelem, de hibázási
lehetőség miatt is. Ez ügyben utánajárok 1 dolognak, pozitiv eredmény
esetén megírom.


> > 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)).

Szerintem elbeszélünk egymás mellett... Te arra gondolsz, amikor már a gép
bejelentette az elvesztést és annak díja is rajtavan a felszólítón
esetleg?
Én a 3. felszólítóról beszélek, ami a perlést megelőzi, az már ajánlottan
kell(ene) menjen.


> > 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.

Egyetértek! Nem mondtam, hogy készítsenek MTA-t ;-)


> 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.

Valahogy azért kezelni kellene legalább a:
- átadtuk kiküldésre az MTA-nak
- nem kézbesíthető (esetleg ezt kicsit árnyalni)
- kézbesítve

> 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.

Ahogy - gondolom én - Te is szétválogatod a leveleket bizonyos szempont
alapján, úgy a visszajövő leveleket is szét lehet, a hibakódok nagyrész
megegyeznek MTA-tól függetlenül, az esetleges eltéréseket pedig lehet
korrigálni (regexp).

Ott érzem még kicsit sántának a dolgot, hogy aki nem saját MTA-val
rendelkezik, annak macerásabb lehet az egész.


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

Ahogy én gondolom:
1. Kézi indításu e-mail felszólító indítása, vagy időzítő indítja ugyanezt
a funkciót.

2. Levelek átadása MTA-nak (ami 1-2 órán belül vagy elküldi vagy
visszadobja, több napos próbálkozást kizárnám az MTA-ból)

3. Ami visszajön, azt a hibakódnak megfelelően visszadnám a TL-nek, hogy
rögzítse  kézbesíthetetlenséget, esetleg okát.

4. Ami nem jön vissza 2 óra 10 perc mulva, azt úgy veszem elment (MTA
beállítás alapján), ezt is berügzítem TL-be.

5. Összegző levelet meg lehet fogalmazni az adminnak, hogy: reggel
7:00-kor kézbesítésre átadva 87 levél, ebből visszajött 14. A 14 meg
TL-ben lekereshető, szükség szerint részükre újra lehet próbálkozni vagy
megszüntetni az e-mail-es címüket (inaktiválni?), hogy mehessen a postai
11:00 órától.


> 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.

Így van és saját MTA esetén sokkal több lehetőség van.


> 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.

Az ötlet remek! Beiratkozik, levél kiküld, ha visszajön egyből, akkor
látható a hiba (visszacsatolás szükségessége).


> 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?

Az e-mail cím beírásakor az alap ellenörzés minimum meg kell lenni! Legyen
benne @, az azt követő részben legalább egy pont, az utolsó pont utáni tag
2 vagy 3 karakter. PHP esetén a @ utáni rész MX-ét is lehet csekkolni, ez
esetben kérdőjeles....

> Email címet weben változtatni kell. Miért? Mert egyszerűen változhat.

Nem kérdés - imho.

> Ehhez mi kell? Mostani olvasói állapotnál biztonságosabb login. böngésző
> vissza gombja..+titkositatlan jelszó (hash szükséges js oldalon)

Ennek egy részére megoldás a https, JS-t ki kellene hagyni a dologból -
szerintem


> 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..

Saját magának is több lehet, ez tiszta, a szülő, apa szerintem nem ide
tartozik, hacsak nem jótálló, de akkor meg ott a helye a jótálló adatai
között.


> > 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.

Nem voltam...


> 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.

Ezek szerint közel áll a befejezéshez is? ;-)

> 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.

Nem egészen vágom a "jóságát", de mivel ez kevéssé érint így inkább most
hagynám...


> É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?

Mivel a konzorcium könyvtárai egy közös felületet hoznak létre, így az
adatokat tovább kell(ene) szolgáltatni, vagy legalábbis a lehetőségét
megteremteni.


> Jelentkezzen valaki, akinél ez VALÓS igényként felmerült. Vagy bárhol
> hátrányként jelentkezett.

Én most elsősorban a pályázat szempontjából nézem a fejlesztéseket. Az
ötlet jó (z39.50), a kihasználtsága esetleg kérdőjeles, viszont a
pályázatban elfogadták (az együttműködésen volt a hangsúly és nem csak a
konzorciumi tagok között), így mos meg is kell(ene) csinálni. Mondjuk úgy,
hogy hátrányként nem jelentkezett, viszont problémás lesz, ha nem valósul
meg.


> 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.

Persze, de amikor határidőre kell működni valaminek akkor nem mindig a
szépséget nézi az ember, hanem azt, hogy működik -e? :-)

DBF_LST-re nekem is van ötletem, csak épp időm nem sok, így mindig
tolódik.. ;-)

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

Új threadbe mehet... bár nem bánnám, ha a többiek esetleg kicsit
aktívabbak lennének ;-)

-- 
  (O__	  ------------------------------------------------------
  //\                       /      Varosi Csokonai Konyvtar
 //  )                     |       Tel.: 59/503-152
 V__/_    szistvan at tux.hu   \      szistvan at mail.vcsk.hu