Offline, DB nélküli LAN chat - hogyan?

Algoritmusok

Sziasztok,

Szeretnék egy offline chat jellegű programot készíteni (lényegében adott problémákat lehetne felvenni, majd arra válaszolni). A programhoz nem használható semmilyen DB, viszont a kommunikációhoz van egy megosztott mappa amit minden gép elér. A felhasználók nincsenek egyszerre online, így mindenfajta üzenetküldés kilőve, viszont a problémákról és arra kapott válaszokról nekik is értesülniük kell.

A jelenlegi legjobb ötlet, hogy minden problémára indított beszélgetési szál egy szöveges fájl lenne a megosztott mappában, timestamppel. Így a kliensek időnként megnéznék, hogy frissült-e, és ha igen, akkor végigolvasnák. Ha valaki hozzászól, akkor ezt a fájlt frissítené.
A probléma az, hogy elméletben hozzáférhetnek többen, egy időben, bár erre kicsi az esély (egyszerre max 50 online felhasználóval).

Ti hogyan állnátok neki egy ilyen program megvalósításának? (Nem a programozás résznek!)

  • 7386 megtekintés

( psc | 2013. 04. 27., szo – 23:07 )

visszautaznék fejben az időben 20-30 évet, s elgondolkoznék, hogy pl. a dbase meg hasonlók hogyan működtek hálózatos tárhelyen...
aztán kicsit gondolkoznék, hogy a maildir hogy működik...
ezután gondolkoznék, hogy akár firebird sql-t vagy sqlite -t vagy hasonlót sem lehet-e használni...
s finomítgatnám az ötletet...

A helyzetet valószínűleg megkönnyítené, ha lenne egy szerver program, ami kezelné a kliensek dolgait, de jelen esetben csak kliensek vannak.
Az SQLite nekem is eszembe jutott, de ugye az is egy fájlban tárol mindent, amit nem biztos, hogy szerencsés egyszerre több kliensnek módosítania.

Maildirnek utánanézek, köszi

( vl v | 2013. 04. 27., szo – 23:25 )

Szerintem a "megosztott mappa" nevű fogalom szemantikájával kerüljél tisztába először (milyen műveletek végezhetők el rajta, azokra az adott megosztási protokoll milyen konzisztenciát garantál, lockolás hogyan működik, stb.), mielőtt ilyenekben gondolkodsz.

Amúgy fel nem fogom, hogy egy csak LAN-on működőképes, mindenki által elérhető könyvtárat igénylő valamit 2013-ban minek gyártani... Ez a 90-es évek közepén volt menő, kb. a Novell Netware tündöklése idején.

pl. banki terminálprogramok is így működnek, a mai napig.
feltelepíted egy osztott mappába, s a gépekre egy parancsikont hoz létre lényegében.
előnye, hogy működik, és nem kell kijelölt sql servert telepíteni, karbantartani, hanem megkapod a cd-t, telepít, hálózati meghajtó kiválaszt, s máris megy a dolog.
arra, amire kell, pont ez való.

( iwanabeguru | 2013. 04. 27., szo – 23:43 )

Olyan iskolai feladat szaga van ...

Csak néhány gondolat:
-Minden napnak külön könyvtár a megosztott tárhelyen belül
-minden üzenet külön file
--file nevében tárgy,feladó,időbélyeg, ha válasz akkor a megválaszolt üzenet tárgya és feladója
pl: nincs_kavé.START.béla.béla.[timestamp].txt
re_nincs_kavé.nincs_kávé.béla.juli.[timestamp].txt
-kliens tárolja az utolsó szinkronizálás időpontját és ahhoz képest szinkronizál
Hmm kisértetiesen hasonlít valami levelzéshez

1. Tegyél alá adatbázist.
2. tuti létezik már valami hasonló program
===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

,, kellemes lesz feldolgozni az ezernyi file-t, kitalalni hogy mire mi a valasz, stb..."

A megjelenítés elküldés ideje szerint sorba megy a fileokon/üzeneteken, nem kell neked azzal törődnöd, hogy mire válasz. Esetleg megjelenítéskor kezelheted ha valaki szövegében üzenetID szerű karakterláncot látsz, és csinálhatsz belőle linket.
Pont ahogy minden normális fórum, chat, mail list megjelenítő tenné.

Puppy linux felhasználó

"Olyan iskolai feladat szaga van..."
Melóban az információ megosztás a részlegek között email alapú.
Az infóra 0-24ig szükség van, de műszakkezdéskor nem egyszerű a több száz emailből összeállítani mindenkinek egyénileg, hogy melyik problémára pontosan kinek, mi volt a válasza és megoldódott-e végül a probléma.
Itt meglenne minden, egyben, mindenkinek.

Még annyit, hogy a policy által megengedett 13 éves Lotus nem támogatja a fa-struktúra nézetet az emaileknél...
Lehet vitatkozni, hogy ilyen policynak mennyire van értelme, de ez a topic most nem arról szól, amin úgy sem tudunk változtatni.

"tegyél alá adatbázist" -> nem tudok, de ez a téma címében is benne van. Hogy őszinte legyek, szerintem nem is szükséges.

( psc | 2013. 04. 28., v – 00:20 )

amúgy inkább úgy csinálnám, hogy:
- minden beszélgetési szál egy mappa, amiben mindegyikben van egy "NEW" nevű almappa.

- a kliens lekéri a mappalistát, ezek a beszélgetési szálak, kilistázza őket a programban. (esetleg lehet azt csinálni,
hogy a mappanevek egszerűek, rövidek, mondjuk novekvo sorszamuak, semmi egyeb, s a mappán belül van mondjuk egy description nevű fájl szöveges fájl, ami tartalmazza a szál témáját, nyitó user nevét, stb..)

- ha valamelyikre kiváncsi az user, akkor listázza a mappa tartalmát, ahol minden egyes válasz egy-egy külön szöveges
fájl, nevében mondjuk a feladó user neve és timestamp, benne az üzenet. ezeket a program meg tudja jeleníteni sorban.
(esetleg ezekben a fájlokban meg lehet oldani, hogy pl. az 1. sor annak a másik, szálon belüli szöveges fájlnak a neve, amire ez közvetlen válasz. így meg lehet oldani, hogy egy-egy válaszra, bejegyzésre több válasz is legyen, hogy az egész ne csak egy egyszerű chat-szerű akármi legyen, ahol a threadhoz csak hozzászólni lehet folytonosan, de egyes válaszokra már nem lehet válaszolni. ez a feldolgozást, listázást picit bonyolítja, mert nyílván kell tartani hogy mi mire a válasz, láncolt listát kell építeni, nem elég folyotonosan kilistázni a szöveges fájlok tartalmát.)

- ha új üzenetet írunk a szálba, akkor a megfelelő szöveges fájl a szál mappáján belüli "NEW" mappában készíti el. amint
befejezte a szöveges fájl írását, egy move/rename rendszerhívással áthelyezi a NEW mappából a beszélgetési szál mappájába. evvel az a probléma kiküszöbölve, hogy ha esetleg a másik kliens épp akkor listázza ki a válaszokat, amikor ennek az írása még nem fejeződött be. (ha a fenti "description" fájlos megoldást alkalmazzuk a szál támájának, egyéb adatainak tárolására, akkor azt a description fájlt is a NEW almappában kell létrehozni, s move/rename rendszerhívással áttenni a szál mappájába.)

a fenti módszer mentén elindulhatsz, így nem kell lock- meg egyéb fájlokkal, műveletekkel sem bonyolítani a dolgot.
a módszer egyszerű, mint a faék, nem is kell ennél jobban bonyolítani.
ha kell törölni is, akkor azt úgy oldanám meg, hogy lenne egy "DELETED_THREAD" mappa az egésznek a gyökerébe, ahová move/rename rendszerhívással áthelyezed
az egész beszélgetési szál mappát, ami szálat törölni akarsz. a beszélgetési szálak mappáján belül is lenne egy "DELETED" mappa, amibe az egye üzeneteket lehetne rename/move rendszerhívással áthelyezni. szükség esetél ezekből a mappákból fizikailag is eltávolítható később az adat, ha szükséges.

Telitalálat, köszönöm!

Kicsit továbbgondolva a dolgot, a programot célszerű a hálózati helyen tárolni.
A program egyéni fájljait is ide lehetne létrehozni, pl a bejelentkezett user automatikus kiolvasásával. Arra gondoltam, hogy minden beszélgetési szál mappájában lehet egy fájl a a kliens felhasználónevével, amibe beleírja minden olvasásnál, hogy mi volt az utolsó fájl, amit már látott. Így a program akkor is működne, ha nem a szokásos gépét használja valaki. Ezt a fájlt biztos, hogy nem szerkeszti más egy időben, mert ez csak az adott felhasználóé.

A szál törlése sem egyszerű eset, mert amíg egy szál az egyik felhasználónak megoldott probléma, addig egy másik felhasználó még nem is olvasta azt és lehet, hogy további választ fűzne hozzá.
Arra gondoltam, hogy mindenki egyénileg nyomhatna rá, hogy számára ez a problémaszál megoldott. Ekkor ezt a szálat már nem mutatná az adott kliensnek, kivéve, ha új üzenet érkezik rá.
Ha mindenki rányomott, hogy megoldva, akkor senkinél sem jelenik meg többé, nincs aki újraélessze. Ebben az esetben a szál törölhető.
Ezzel viszont a "mindenki" definíciója a probléma, amihez kell egy felhasználólista.

( ironcat | 2013. 04. 28., v – 10:12 )

Esetleg: news server és news client.

-----
A kockás zakók és a mellészabások tekintetében kérdezze meg úri szabóját.

( furge | 2013. 04. 28., v – 10:22 )

ha már adott egy dedikált gép amin osztott mappában elérhetők a file-k akkor akár lehetne rá egy db-t tenni amiben benne vannak az infók. egyszerűbb az időt, témákat számon tartani.
-------------------------------------------

Hello,

ez esetben nézd meg ezt: http://office.microsoft.com/en-us/templates/desktop-issue-tracking-TC00…
Majd' mindent tud, amit Te leírtál, két dolgot meg kell csinálni még:
-mentse el az adott felhasználót azonosító stringet is a Comment mező módosításakor az Issue Details formon.
-legyen szétválasztva a form és az adatbázis, hogy többen tudjátok használni egy időben.
A többi OK-nak tűnik.

Üdv,
Marci

Értem én, hogy írtad feljebb, de miért írod ezt nekem? Mi itt elötletelgetünk, ő meg - ha ránk hallgat - azt csinál, amit akar.

(Teszem fel a topicnyitó, ha a Notes a standard náluk és ismeri, hogyan kell fejleszteni rá, már megcsinálta volna abban és nem nyit topicot.)

Üdv,
Marci