- sj blogja
- A hozzászóláshoz be kell jelentkezni
- 831 megtekintés
Hozzászólások
Ehhez lehet, hogy kell valami AJAX-os lopikula.
- A hozzászóláshoz be kell jelentkezni
kicsit pszeudophp lesz, de en igy csinalnam meg:
<?
$lines= `tail --lines=+{$GET['from']} | grep xxx | wc -l`;
?>
< body onload="javascript:document.location.href='script.php?from='<?echo $lines+$_GET['from']; ?>;">
<?
echo `tail --lines=+{$GET['from']} /foo/bar | grep xxx`;
?>
- A hozzászóláshoz be kell jelentkezni
termeszetesen inputot meg validalni kell meg ilyesmi, esetleg a reload resznel sleepelni, megnezni hogy a backticknel lehet e igy valtozot atadni, ha nem akkor system() mel megoldani, mondom, pszeudophp :)
- A hozzászóláshoz be kell jelentkezni
2 reszre osztanam a problemat: az egyik, hogy egy terhelt serveren hogy all elo egy nagy file utolso x sora. A masik, hogy hogy kerul at real-time a bongeszore.
egyszeru eset:
Az elsore lehet jo megoldas, ha egy daemon olvassa a logot, ami blokkolodik irasok kozt, de mindig tovabb olvas, amikor jon 1-1 uj sor.
A legegyszerubb eset, ha fejbetartja (memoriaban) az utolso x sort, es mindig amikor bejon egy uj, kiirja a megfelelo mennyiseget egy file-ba, amit a webserver is eler. Ha kicsit akarod bonyolitani (vagy gondolsz a jovore), akkor szetparse-olod a log minden sorat, es beleteszed egy DB-be valami ertelmes modon, hogy keresheto legyen.
A scripted (lehet PHP, ilyen szempontbol teljesen irrelevans) innen beolvassa, es megjeleniti. Real-time persze nem lesz, de frissitheted tetszoleges idokozonkent (pl: meta refresh), vagy athuzhatod ajax-szal.
a masik, real-time-abb eset:
Ez feltetelezi, hogy valamennyire tisztaban legyel az ajax-szal. Idonkent kenytelen leszel frissiteni az oldalt, de joreszt magatol tud frissulni. Azt nem tudom mennyire kell meghackelni az apache-ot hozza, valoszinuleg nem egyszeru.. (meg nem csinaltam ilyet, csak olvastam rola)
Szoval: a legtobb bongeszo mar akkor megjelenit egy oldalt, amikor meg nem toltodott be teljesen. Ezt trukkosen ki lehet hasznalni, elore nem mondjuk majd meg a headerben, hogy mekkora az oldal, es nem is hagyjuk, hogy teljesen letoltse - mert nincs vege. Amikor a bongeszotol megjon a keres, at kell kuldeni az oldal szerkezetet, es utana - anelkul, hogy lezarnank a body-t - atkuldunk neki egy script tag-et, amiben egy js koddal frissitjuk a tartalmat. De nem zarjuk le a kapcsolatot server oldalon, hanem figyeljuk, hogy jott-e uj sor a logba, es ha igen, megint generalunk egy uj script tag-et, atkuldjuk, es meg mindig nem zarjuk le a kapcsolatot..
Elonye, hogy ha a scriptunk megfeleloen figyeli (pl. blokkolodo olvasassal) a logot, gyakorlatilag azonnal megjelenik a valtozas a bongeszoben. Hatranya, hogy a modszer az egesz rendszer szethekkelese, nem feltetlenul mukodik minden bongeszon. A bongeszo ugy fog viselkedni (azt jelzi), hogy nem toltodott le az oldal, ami a felhasznalot zavarhatja. Szinten gond (persze megoldhato akar refresh tag-gel akar js koddal), hogy idovel a bongeszo egy hatalmas html oldallal fog birkozni, ami lelassitja a rendszert. Ja, es sokkal tobbet kell hozza kodolni.
--
Vorbis megváltoztatta az embereket. Néha halott emberekké változtatta őket. De mindig megváltoztatta őket. Ez volt az ő diadala. - Pratchett
- A hozzászóláshoz be kell jelentkezni
Meg valami:
Kevesebb hackelessel is megoldhato a 2. eset az 1. esettel. Megteheted, hogy ha jon egy AJAX keres frissitesre, akkor ha van uj adat, rogton visszaadod. Ha nincs, nem valaszolsz rogton, hanem varsz egy picit (mondjuk 30 sec-et). Ha azalatt jon uj adat, akkor azt visszakuldod. Ha nem jon, akkor visszauzensz, hogy nem volt uj, es a kliens uj kerest kuld. Szoval barmikor vissza tudsz uzenni a bongeszonek amint jon uj bejegyzes.
--
Vorbis megváltoztatta az embereket. Néha halott emberekké változtatta őket. De mindig megváltoztatta őket. Ez volt az ő diadala. - Pratchett
- A hozzászóláshoz be kell jelentkezni
Az a terv, hogy szetparse-olom, aztan db-be tolom. Onnan egyszerubb rekonstrualni, hogy mi tortent egy levellel. Ami a demont illeti, az a terv, hogy irok egy File::Tail-t hasznalo scriptet. Remelem, a log rotalast kezelni tudja...
SPAMtelenul - POP3 spamszuro szolgaltatas
- A hozzászóláshoz be kell jelentkezni
PHP -vel gondolom fel tudod dolgozni, egy XMLHttpRequest() setTimeout() -al kombinálva pedig
akár ms -enkent is tud frissíteni.
Célszerű mindíg csak egy adott sort lekerni, mondjuk 0,5 sec refresh-el, az előzőhöz hozzáfűzni.
Nem nagy ördöngősség.
"-Pedig vegetariánus vagyok; csak növényevő állatokat fogyasztok!"
azenoldalamponthu
- A hozzászóláshoz be kell jelentkezni
egy próbát megér: phpLogCon
--
by Mikul@s
- A hozzászóláshoz be kell jelentkezni
Kossz a tippeket mindenkinek, eloszor a maillog turas jon.
SPAMtelenul - POP3 spamszuro szolgaltatas
- A hozzászóláshoz be kell jelentkezni
Jelentem, mukodik a dolog. Egy perl script a File::Tail modul segitsegevel fogja es olvassa a maillogot. Az erdekes sorokat kiszedi, parse-olja, majd (gondolkodtam nyos terhelt mysql szerver dolgan, ezert) egy SQLite3 file-ba tolja az adatokat.
Ez volt eddig az easy part. A nehezebb az, hogy valami elegansabb modon frissuljon a mail history a bongeszoben, anelkul, hogy nyomkodni kene a refresh gombot, ill. a meta refresh-nel is szebbet akartam.
Szoval ajax lett a vege. Amikor az oldal betoltodik, akkor egy cookie-t is dob a kliens gepere. Egy javascript ajax-szal megkerdezi egy php scripttol a db file legutolso bejegyzesenek timestamp-jet. Ha frissebb, mint a cookie-ban kapott 'lastupdate', akkor egy szinten ajax fuggvennyel lekerdezem a legfrissebb ~15 levelhez tartozo bejegyzest, ami egy 'span' tag tartalmaba irodik be, amit az FF jol megmutat. Ennyi, es megegyszer kossz mindenkinek a tippeket.
SPAMtelenul - POP3 spamszuro szolgaltatas
- A hozzászóláshoz be kell jelentkezni