ajax reload
- Honza Kuchař
- Člen | 1662
Já přesně na tohle plánuji tzn. „Rich HTTP“. (zatím mám takový koncept :D ) Můžu postytnout naskenovaný papír, jak to má fungovat. Na implemetaci zatím není čas. Nicméně funkční implemetovanou verzi používá např.: Google Docs. (Samozdřejmě ne tu moji)
Krátce: funguje to tak, že po načtení stránky se pošle AJAX požadavek na server. Server neodpovídá… V pozadí na serveru běží cyklus, který dokud není žádná změna dat pokračuje pořát dál. Pokud nastane změna dat, tak se vygeneruje odezva a odešle. Tím se ukončí spojení. Klient okamžitě navazuje nové. Atd. Atd.
Aby bylo možno zjistit, jestli se klient odpojil, tak se na výstup posílá
každou sekundu mezera. Ovšem nevím co udělá mezera na začátku v JSON,
takže možní obalit /* <tady ty mezery> */{json}.
(testováno na Moz, Chrome)
P.S.: Původní nápad přišel už někdy před 2 lety, kdy jsem chtěl zjistit, jak dlouho uživatel na stránce pobývá. Implemetace byla skutečně funkční, tak technicky by v tom neměl být problém.
- redhead
- Člen | 1313
Mě to zní hezky, a jednoduše. Jen by mě zajímalo, když ten cyklus na straně serveru je u každého uživatele, co na to výkon serveru?? Není to potom celé takové pomalé? Do těhle věcí moc nevidím, jen se ptám, protože mě to hned po přečtení napadlo. Ale jinak se mi ten nápad libí :D
- JakubKohout
- Člen | 92
honzakuchar napsal(a):
Já přesně na tohle plánuji tzn. „Rich HTTP“. (zatím mám takový koncept :D ) Můžu postytnout naskenovaný papír, jak to má fungovat. Na implemetaci zatím není čas. Nicméně funkční implemetovanou verzi používá např.: Google Docs. (Samozdřejmě ne tu moji)
Krátce: funguje to tak, že po načtení stránky se pošle AJAX požadavek na server. Server neodpovídá… V pozadí na serveru běží cyklus, který dokud není žádná změna dat pokračuje pořát dál. Pokud nastane změna dat, tak se vygeneruje odezva a odešle. Tím se ukončí spojení. Klient okamžitě navazuje nové. Atd. Atd.
Tento princip je popsán také například zde: http://principyprogramovani.blog.zive.cz/…rogramovani/
Ale zajímá mě pohled z hlediska PHP, hlavně ta realizace. Aby na pozadí běžel neustále php skript je blbost, protože by se po 60ti sekundách stejně ukončil, tak přemejšlim jak to zapsat. Určitě bych to potřeboval pro PUSH notifikace do redakčního systému, kdy se zobrazí například „Uživatel také edituje tento článek“ jako je v google docs.
- DocX
- Člen | 154
radvis napsal(a):
.. Neznáte někdo prosím na to tutorial? Díky…
Já bych to viděl na nějakej tutoriál … bez tutoriálu to nezvládnu:( .
… Pro mě by bylo asi nejjednodužší si přečíst tut …
Nevim nevim, ale tohle asi není to správné místo.
dRaGen napsal(a):
Ale zajímá mě pohled z hlediska PHP, hlavně ta realizace. Aby na pozadí běžel neustále php skript je blbost, protože by se po 60ti sekundách stejně ukončil, tak přemejšlim jak to zapsat. Určitě bych to potřeboval pro PUSH notifikace do redakčního systému, kdy se zobrazí například „Uživatel také edituje tento článek“ jako je v google docs.
Pokud máš vlastní server nebo pronajatý VM, tak si PHP můžeš nastavit bez limitu. Jinak myslím, že Google tohle nemá postavé na PHP, ale na něčem jako Python nebo Perl (ale můžná kecám). Jinak je to zajímavá myšlenka :)
- JakubKohout
- Člen | 92
jasně, server by nebyl problém, ale čas běhu php skriptu neni udělanej
pro srandu, takže to neni řešení a nastavovat běh skriptu třeba na
20 minut au au au :)
Nepočítaje to že to stejně musí koukat do DB jestli se něco nezměnilo
což je taky další naprd řešení…
Postavit to na jinym jazyku než PHP bude zase problém z hlediska toho že HTTP je bezstavový, jak poslat data tomu správnýmu uživateli a né někomu kdo s tim nemá vůbec nic společnýho
- DocX
- Člen | 154
dRaGen napsal(a):
jasně, server by nebyl problém, ale čas běhu php skriptu neni udělanej pro srandu, takže to neni řešení a nastavovat běh skriptu třeba na 20 minut au au au :)
Nepočítaje to že to stejně musí koukat do DB jestli se něco nezměnilo což je taky další naprd řešení…
Ten limit je tam podle mě hlavně proto, když je PHP na hostingu, aby někdo, ať už schválně nebo ne, nezablokoval celej server. Pokud si budu psát PHP dobře tak, že se nikdy nebude moc stát nějaký nekonečný cyklus, je to IMHO v pohodě. Ale 20 minut je asi fakt moc :) Takže možná třeba 5 minut, pak poslat zprávu „nic se nezměnilo“ a klient by navázal nové spojení.
Postavit to na jinym jazyku než PHP bude zase problém z hlediska toho že HTTP je bezstavový, jak poslat data tomu správnýmu uživateli a né někomu kdo s tim nemá vůbec nic společnýho
Tomuhle nerozumím, dyť to spojení je na úrovni TCP, pokud se s klientem něco stane, TCP spojení se přeruší. Nebo jak by mohl někdo jiný „ukradnout“ TCP spojení? (Jde to, ale to sem teď nechci tahat)
- JakubKohout
- Člen | 92
DocX napsal(a):
Tomuhle nerozumím, dyť to spojení je na úrovni TCP, pokud se s klientem něco stane, TCP spojení se přeruší. Nebo jak by mohl někdo jiný „ukradnout“ TCP spojení? (Jde to, ale to sem teď nechci tahat)
Spíš mě napadlo to řešit stylem … někde vstoupí do článku a všem klientům co maj poslaný žádost, tak pošlu odpověď.
Teď by to vypadalo nějak takto
/* (90 * 10) / 60 = cca 15minut */
for ($i = 1;$i<91;$i++){
/* vratí data když se stalo něco novýho od posledního update, jinak false */
if($tmp = $this->model->getNewRows($last_update_time) !== FALSE){
return $tmp;
}
sleep(10);
}Využití že bych při nějaký akci pushnul data pro všechny otevřený spojení by byla hezčí ale technicky asi nemožná :/
- DocX
- Člen | 154
dRaGen napsal(a):
Spíš mě napadlo to řešit stylem … někde vstoupí do článku a všem klientům co maj poslaný žádost, tak pošlu odpověď.
Jo takhle :) No to by bylo pěkný :) Možná až bude rozjetý IPv6 a zaběhnutý multicastování :) Ale i tak by jsi asi musel zjišťovat jestli je to změna, která se opravdu projeví všem, jinak by jsi musel vždycky použít unicast.
/* (90 * 10) / 60 = cca 15minut */
To je přesně 15 minut ;)
- JakubKohout
- Člen | 92
DocX napsal(a):
Jo takhle :) No to by bylo pěkný :) Možná až bude rozjetý IPv6 a zaběhnutý multicastování :) Ale i tak by jsi asi musel zjišťovat jestli je to změna, která se opravdu projeví všem, jinak by jsi musel vždycky použít unicast.
Určitě je to hodně hezký řešení, ale IPv6 je hudba budoucnosti a je to spíš zacyklený kolečko slepice-vajíčko …
Ale třeba to takhle už maj řešený ty velký portály, že jim přijde na vstup serveru spojení který obsahuje data v postu (id uživatele, id clanku napr.) tak to naparsujou poupraví a zaškatulkuje tohle ID spojení k čemu má přístup. Pak po nějaký akci jenom vezmou id spojení který k tomu maj mít přístup a pošle jim data.
Pro klienta je to pořád stejný, on to nepozná ale bůh ví jak to maj řešený na serveru.
To je přesně 15 minut ;)
Neni to přesný protože je tam ještě ten dotaz do databáze, kterej si sice sežere cca 0,1 sekundy na těch 90cyklů ale je to prostě relativní čas 15minut :)
- Majkl578
- Moderator | 1364
dRaGen napsal(a):
Ale zajímá mě pohled z hlediska PHP, hlavně ta realizace. Aby na pozadí běžel neustále php skript je blbost, protože by se po 60ti sekundách stejně ukončil, tak přemejšlim jak to zapsat. Určitě bych to potřeboval pro PUSH notifikace do redakčního systému, kdy se zobrazí například „Uživatel také edituje tento článek“ jako je v google docs.
pokud se jedná o vlastní server, tak by možná bylo lepší, kdyby se to neřešilo přes php, ale přes nějaký standalone server (např. napsaný v c++), který by běžel pořád a přijímal požadavky. takhle nějak funguje XMPP pokud se nemýlím…
- DocX
- Člen | 154
Majkl578 napsal(a):
pokud se jedná o vlastní server, tak by možná bylo lepší, kdyby se to neřešilo přes php, ale přes nějaký standalone server (např. napsaný v c++), který by běžel pořád a přijímal požadavky.
Jj, to je úplně best řešení, ale někdy je ekonomické, někdy ne. Jeden známí dělal takový ten web co zprostředkovává RapidShare (nebudu jmenovat :). Nejprve to dělali v ASP.NET + IIS, ale prostě jim to pořád nejelo dostatečně rychle, tak udělali celý vlastní HTTP server v C#.
takhle nějak funguje XMPP pokud se nemýlím…
XMPP nemá, pokud se nemýlím, nic společného s HTTP. Jinak je to samostatná platforma a XMPP servery jsou implementovány jako valstní program/demon. Ale nevím, jestli se klient připojí a spojení drží, ale je to dost možné :)
- Majkl578
- Moderator | 1364
Ondrej napsal(a):
standalone TCP server lze napsat i v PHP
to ano, ale je to takové kostrbaté, jelikož PHP na to není stavěné.
DocX napsal(a):
XMPP nemá, pokud se nemýlím, nic společného s HTTP. Jinak je to samostatná platforma a XMPP servery jsou implementovány jako valstní program/demon. Ale nevím, jestli se klient připojí a spojení drží, ale je to dost možné :)
samozřejmě jsem to myslel ve spojení s ajaxem například přes BOSH. takhle přeci funguje i facebook chat, mají javascriptového klienta (konkrétně nevím, nikdy jsem na facebooku nebyl)
- DocX
- Člen | 154
Majkl578 napsal(a):
samozřejmě jsem to myslel ve spojení s ajaxem například přes BOSH. takhle přeci funguje i facebook chat, mají javascriptového klienta (konkrétně nevím, nikdy jsem na facebooku nebyl)
Jo tak. No na facebooku je součástí rozhraní chat. Ale myslím že to není XMPP, jinak by se na to dalo normálně připojit z jabber klienta. Ale to nejde. I když pár klientů na to je, ale ty myslím jen dělají to co by dělala ta originální stránka v JS.
No ale jinak jako obecné řešení mě nenapadá nic jiného než to, co tu bylo už zmíněno – klient otevře spojení, server čeká až se něco stane a pošle echo klientovi. Nebo možná že by se klient periodicky ptal serveru. Ale jak často? Aby to zas nebylo moc náročné na počet spojení a aby to bylo relativně interaktivní.
- Majkl578
- Moderator | 1364
DocX napsal(a):
Majkl578 napsal(a):
samozřejmě jsem to myslel ve spojení s ajaxem například přes BOSH. takhle přeci funguje i facebook chat, mají javascriptového klienta (konkrétně nevím, nikdy jsem na facebooku nebyl)
Jo tak. No na facebooku je součástí rozhraní chat. Ale myslím že to není XMPP, jinak by se na to dalo normálně připojit z jabber klienta. Ale to nejde. I když pár klientů na to je, ale ty myslím jen dělají to co by dělala ta originální stránka v JS.
No ale jinak jako obecné řešení mě nenapadá nic jiného než to, co tu bylo už zmíněno – klient otevře spojení, server čeká až se něco stane a pošle echo klientovi. Nebo možná že by se klient periodicky ptal serveru. Ale jak často? Aby to zas nebylo moc náročné na počet spojení a aby to bylo relativně interaktivní.
asi je na místě dodat článeček, kde se o tom trochu píše :)
například pidgin facebook plugin má, v debian repositáři je to balík
„pidgin-facebookchat“
- Honza Kuchař
- Člen | 1662
Jinak myslel jsem samozdřejmě ověřím, chvilku počkám. Ověřím… Už mám vymyšlenou implemetaci. Myslím, že to bude dost cool, bude to poslavené jakoby na callbackech.
Google tohle nemá postavé na PHP
Pokud vím, tak jsem slyšel něco o Javě.
Editoval honzakuchar (12. 10. 2009 10:40)
- JakubKohout
- Člen | 92
Dnes sem to řešil a narazil jsem na zajimavou knihu o tomto:
comet and reverse ajax 2.0
- Dragon Jake
- Člen | 20
Nedávno jsem v rámci projektu napsal ve spolupráci s Nette monitorovacího daemona v PHP. Běží přes CLI na serveru a v sekundovém intervalu tahá data z db a spouští monitoring serverů. Kdyby někdo chtěl skeleton jak na fork, mohu zaslat ;)