---

Igen-igen. Min chatbox driller. Og jeg har mistanke om, det er nogle
ting, som konflikter. Så her er noget hjernevridning for de kloge...

Link: http://runejensen.dk/tips/ajax/shoutbox.asp

Problem:

Jeg har lavet to timere, en timer til at hente og opdatere chatbox (
timedCount();) og en til ditto brugere online (timedCount2(); ).
Problemet er (så vidt jeg har forstået) de ikke tager højde for, om
der allerede er en hent i gang, så de (måske) kommer til at afbryde
sig selv.

Der er blevet foreslået at slukke for aktuel timer (man bør vel så
kunne bruge en global variabel), når hent er i gang, men dette kan jeg
ikke få til at virke. Timeren skal jo også sættes i gang igen, når
hent er færdig.

Ovenstående vil vel også give problemer, hvis der ikke er tid, når
timeren trigges, f.eks. give _meget_ lang opdateringstid, fordi der så
først tjekkes igen ved næste timertimeout?

Omvendt kunne man så sætte en hulens høj opdateringstid, men det vil
vel så give serverload mm...

En løsning kunne jeg forestille mig er en variabel, som bare
fortæller, om der er request på hent, og så hvis den er sat udfører en
hent i readystate (når sidste hent er færdig), hvorefter den nulles
igen.

Intet af det kan jeg få til at virke tilfresstillende - sikkert fordi
jeg ikke er en ørn til det mere avancerede JS.

Jeg har flere problemer, men dette er hovedproblemet og det vigtigste
at få løst. Nogen med nogle gode råd?



Underproblemer, som måske er en del af ovenstående:
- I IE7: Chatboksen opdateres i små ryk i scrollToBottom(). Det burde
ikke være nødvendigt, hvis den udregner højde rigtigt i
scrollToBottom(). Min vistid() switcher virker ikke.
Opdateringshastighed ser dog rigtig ud.

- I FF: Vistid() switcher virker ikke. Opdateringstiden synes for
hurtig. Brugere online scroller til top hver gang timeren trigges


MVH
Rune Jensen

---

Rune Jensen wrote:
> Igen-igen. Min chatbox driller. Og jeg har mistanke om, det er nogle
> ting, som konflikter. Så her er noget hjernevridning for de kloge...
>
> Link: http://runejensen.dk/tips/ajax/shoutbox.asp
>
> Problem:
>
> Jeg har lavet to timere, en timer til at hente og opdatere chatbox (
> timedCount();) og en til ditto brugere online (timedCount2(); ).
> Problemet er (så vidt jeg har forstået) de ikke tager højde for, om
> der allerede er en hent i gang, så de (måske) kommer til at afbryde
> sig selv.
>
> Der er blevet foreslået at slukke for aktuel timer (man bør vel så
> kunne bruge en global variabel), når hent er i gang, men dette kan jeg
> ikke få til at virke. Timeren skal jo også sættes i gang igen, når
> hent er færdig.
>
> Ovenstående vil vel også give problemer, hvis der ikke er tid, når
> timeren trigges, f.eks. give _meget_ lang opdateringstid, fordi der så
> først tjekkes igen ved næste timertimeout?
>
> Omvendt kunne man så sætte en hulens høj opdateringstid, men det vil
> vel så give serverload mm...

Ligenu henter den ved hvert eneste halve sekund tror jeg, firebug kører
ihvertfald GET igennem konstant... Lidt for ofte synes jeg.. men begge
funktioner virker fint, og få returneret resultat hvergang.

Sammenflet de 2 funktioner user og chat til 1 funktion, evt. så lav en
ny asp side hvor den returnerer begge ting i samme ajax kald, så man
ikke behøver 2 kald, men nøjes med et.

psudo kode (ajax.asp)
----
shoutbox = hent shoutbox.txt
user = hent users.txt
udskriv shoutbox sha1('|||||||') user
----

psudo kode (ajaxdone)
----
variable = hent ajax.asp
shoutbox user = explode(sha1('||||||'),variable)

Nu indeholder shoutbox så shoutbox.txt og user indeholder users.txt

---

Rune Jensen wrote:

> Igen-igen. Min chatbox driller. Og jeg har mistanke om, det er nogle
> ting, som konflikter. Så her er noget hjernevridning for de ...
>
> Link: http://runejensen.dk/tips/ajax/shoutbox.asp

Nå Rune.
Tak fordi du bruger absolutte URI'er, det gør at man(jeg) kan klaske en kopi
på sin kværn.

Lad os starte med at lave 'undo' på hjernevridning, og skille tingene lidt
ad.

Jeg har testet et forslag til nogle rettelser.
Den første ændring er at lade brugertråden leve sit eget liv uafhængit af de
andre tråde.
Samtidig har jeg indført et 'statustjek' i forhold til din server.
Statustjekket virker selvfølgelig ikke korrekt, da det kræver ændringer i
din ASP kode.
Statustjekket går ud på at have et slags versionsnummer, der sendes via en
header til din ASP kode.
I det her tilfælde har jeg kaldt den for 'brugerstatus'.
Ideen går ud på at du i ASP koden får sidste versionsnummer, og hvis der
ikke er 'noget nyt' kan du nøjes med at returnere den samme header uden
yderligere indhold.
På den måde opdaterer man kun hvis der er behov for det.

Det samme gør sig gældende for meddelelser.

Jeg har tilføjet disse 2:
var brugerstatus = '000000';
var meddelsesstatus = '000000' ;

Nu har jeg bare kaldt dem 0'er, som kan bruges til 6 cifrede tællere.

I din function HentFilUsers(url)
har jeg tilføjet:
reqsu.setRequestHeader( 'brugerstatus', brugerstatus);
og i HentFil(url)
req.setRequestHeader( 'meddelsesstatus', meddelsesstatus);
Nu er det heldigvis ikke en ASP gruppe, så jeg kan godt risikere at kvaje
mig, men man burde kunne finde noget a la Request.headers('brugerstatus').

Så er der det med _timerne_. Du starter timerne for tidligt.
Jeg har fjernet (remmet ud)
t1=setTimeout("timedCount()",upDRate); i din timedCount()
og t2=setTimeout("timedCount2()",upDRate); i din timedCount2()

Efter rettelser ser 'else delen' din AJAXDone() sådan ud:
.....
if ( reqsu.getResponseHeader('meddelsesstatus') != meddelsesstatus )
{
document.getElementById('chatbox').innerHTML = req.responseText;
// meddelsesstatus = reqsu.getResponseHeader('meddelsesstatus') ;
}

scrollToBottom();
t1=setTimeout("timedCount()",upDRate);
.....
Og tilsvarende i AJAXDoneSU()
.....
if ( reqsu.getResponseHeader('brugerstatus') != brugerstatus )
{
document.getElementById('users').value = reqsu.responseText;
// brugerstatus = reqsu.getResponseHeader('brugerstatus') ;
}
t2=setTimeout("timedCount2()",upDRate);
.....
Det er først _her_ du skal starte nye timere.
Bemærk at de to statusfelter er remmet ud. Det betyder at det virker, dog
uden server tjek. Hvis du får implementeret serverside status, skal du blot
fjerne //'erne, så burde det virke 'out of the box'.

Jeg er ikke rigtig gået videre med din 'TextSent()', da det er lidt
afhængigt af hvad du beslutter dig til. Men du skal i hvert fald fjerne
HentFilUsers('/shoutboxusers.txt?dummy='+Math.random());

Hvis du laver det her, har vi kun en 'konfliktløsning' tilbage, og det er
ved send mens en meddelsesopdatering er i gang. Men den tager vi når tid
kommer.


--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Nu er det heldigvis ikke en ASP gruppe, så jeg kan godt risikere at kvaje
> mig, men man burde kunne finde noget a la Request.headers('brugerstatus').

Yep, det kunne godt være en kvajer.
Jeg faldt tilfældigvis over denne her:
<http://blogs.msdn.com/david.wang/archive/2006/05/14/HOWTO-Useful-ASP-page-to-retrieve-Request-and-send-Response-Headers.aspx>
Det er fakstisk præcis den funktionalitet jeg havde i tankerne.
Altså ca pseudokode:
Læs statusheader
Hvis uændret i forhold til global, returner kun headeren uændret
Ellers returner global status i header samt ændret indhold

--
Med venlig hilsen
Stig Johansen

---

On 5 Jan., 16:03, Stig Johansen <stig_johansen_it_at_=(@)hotmail.com>
wrote:

> Yep, det kunne godt være en kvajer.
> Jeg faldt tilfældigvis over denne her:
> <http://blogs.msdn.com/david.wang/archive/2006/05/14/HOWTO-Useful-ASP-...>
> Det er fakstisk præcis den funktionalitet jeg havde i tankerne.
> Altså ca pseudokode:
> Læs statusheader
> Hvis uændret i forhold til global, returner kun headeren uændret
> Ellers returner global status i header samt ændret indhold

Måske jeg er helt off-track, men den status kan den ikke bare være
størrelsen af filen? Hvis størrelsen af filen er den samme som sidst,
er den jo ikke ændret?

Kun en tanke, ikke gennemtænkt

MVH
Rune Jensen

---

Rune Jensen wrote:

> Måske jeg er helt off-track, men den status kan den ikke bare være
> størrelsen af filen? Hvis størrelsen af filen er den samme som sidst,
> er den jo ikke ændret?
>
> Kun en tanke, ikke gennemtænkt

Men en godt tænkt tanke

--
Med venlig hilsen
Stig Johansen

---

On 5 Jan., 17:37, Stig Johansen <stig_johansen_it_at_=(@)hotmail.com>
wrote:
> Rune Jensen wrote:
> > Måske jeg er helt off-track, men den status kan den ikke bare være
> > størrelsen af filen? Hvis størrelsen af filen er den samme som sidst,
> > er den jo ikke ændret?
>
> > Kun en tanke, ikke gennemtænkt
>
> Men en godt tænkt tanke

Jeg tog den et step videre med en response-last-modofied. Ser ud til
at virke?


         if ( reqsu.getResponseHeader('Last-Modified') != brugerstatus ) {
            document.getElementById('users').value = reqsu.responseText;
            brugerstatus = reqsu.getResponseHeader('Last-Modified');
            document.getElementById('users').value = reqsu.responseText;
         }

         t2=setTimeout("timedCount2()",upDRate);

MVH
Rune Jensen

---

Rune Jensen wrote:

> Jeg tog den et step videre med en response-last-modofied. Ser ud til
> at virke?

Ja, men vær opmærksom på at det kun vil virke (performancewise) på statiske
filer.
Jeg havde ASP/PHP/... og databaser i tankerne da jeg skrev funktionerne.
Det er rigtigt, at når der er tale om statiske filer, er vi slet ikke inde
og vende i ASP eller lign.
Så du har ret:
Ved statiske filer - brug din metode (Last-Modified header).
Ved dynamiske filer - brug min metode(Custom header).

Jeg skriver ikke det her for at få ret, udelukkende af hensyn til vores
kommende googlegroups besøgende.

--
Med venlig hilsen
Stig Johansen

---

On 5 Jan., 22:55, Rune Jensen <runeofdenm...@gmail.com> wrote:

> Jeg tog den et step videre med en response-last-modofied. Ser ud til

Fandt det her...

http://jibbering.com/2002/4/httprequest.html

....lyder da rigtigt nok?

MVH
Rune Jensen

---

On 5 Jan., 06:30, Stig Johansen <stig_johansen_it_at_=(@)hotmail.com>
wrote:

> Jeg er ikke rigtig gået videre med din 'TextSent()', da det er lidt
> afhængigt af hvad du beslutter dig til. Men du skal i hvert fald fjerne
> HentFilUsers('/shoutboxusers.txt?dummy='+Math.random());
>
> Hvis du laver det her, har vi kun en 'konfliktløsning' tilbage, og det er
> ved send mens en meddelsesopdatering er i gang. Men den tager vi når tid
> kommer.

Jeg overvejer, om man kan slå den sammen med timeren, som opdaterer
users online, og så fjerne hentusers. Fordelen er jo, at det hele
foregår serverside i ét hug. Dvs.

1. Læs message
2. Hvis message <>"" så
3. Opdater Message-filen
4. Tjek user-filen
5. Hvis nogle af brugerne har været for længe på, så slet dem
6. Retur

Der skal så sendes en request om send ved tryk på "send"knappen.

Problemet er stadig, om der konfliktes, men problemet ser mindre ud.

Når jeg tænker over det, så er det måske bedre at lave læs/skriv for
hver som i ovenstående serverside. Det bør stadig kunne gøres med to
timere

Både hentfil og Hentfilusers vil så lave både læse og skriv på
serveren, men ikke samtidig (i samme fil), og der kræves kun to
objecter.

Hmmm...

Jeg er slut, tror jeg, hjernekapaciteten er på nul. Det må blive i
morgen.


MVH
Rune Jensen

---

Rune Jensen wrote:

> On 5 Jan., 06:30, Stig Johansen <stig_johansen_it_at_=(@)hotmail.com>
> wrote:
>> Hvis du laver det her, har vi kun en 'konfliktløsning' tilbage, og det er
>> ved send mens en meddelsesopdatering er i gang. Men den tager vi når tid
>> kommer.
>
> Jeg overvejer, om man kan slå den sammen med timeren, som opdaterer
> users online, og så fjerne hentusers. Fordelen er jo, at det hele
> foregår serverside i ét hug. Dvs.

Nej, nej - lad endelig være med det, nu du har fat i den 'lange' ende.
Jeg kunne godt for lang tid siden have givet dig 'facitlisten', men det
lærer man normalt ikke så meget af.

Jeg gav dig følgende hint:
> Jeg har testet et forslag til nogle rettelser.
Det skulle fortolkes som:
Jeg har *testet* et forslag til nogle rettelser, ved at tilrette en lokal
kopi af *din* side (as in afprøvet og virker).

> 1. Læs message
> 2. Hvis message <>"" så
> 3. Opdater Message-filen
> 4. Tjek user-filen
> 5. Hvis nogle af brugerne har været for længe på, så slet dem
> 6. Retur

Nu er du på vej ud i afgrunden igen.
Der er normalt kun en afslutning (over tid) på den tankegang, og det er en
serialisering, der medfører låsninger osv.
Det der er i virkeligheden en slags pseudo synkronisering af hændelserne,
der er ikke det 'vi' ønsker.

> Der skal så sendes en request om send ved tryk på "send" knappen.

Måske, men der er mere en mental beslutning.
Som der er nu lever meddelserne 'sit eget liv', og det vil fungere perfekt.
Det spørgemål du skal stille dig, og jeg mener du, for det er dit system er:
Når en bruger har sendt en meddelse, skal hans egen (og nye) meddelse dukke
op 'straks' eller kan den vente til næste 'poll' af meddelser?
Vi taler *brugeroplevelsen*. Personligt ville jeg nok ikke opdage om den
kommer 'straks' eller om 1-2 sekunder. Men igen, det er din beslutning.

> Problemet er stadig, om der konfliktes, men problemet ser mindre ud.

Der er en _risiko_ for konflikt. Men det er en kombination af om en bruger
tilfældigvis trykker send samtidig med der er en hent i gang.
Løsningen er ligetil, men det afhænger af din beslutning af ovenstående.

> Når jeg tænker over det, så er det måske bedre at lave læs/skriv for
> hver som i ovenstående serverside. Det bør stadig kunne gøres med to
> timere

Du skal ikke lave noget om i strukturen. Det er som det skal være, og the
best you will ever get.
Det du kunne gøre er at samle de funktioner der hører sammen, og give dem
lidt mere sigende navne. Eks. 'nrugertimeout' i stedet for 'timedcount2'
osv.

> Både hentfil og Hentfilusers vil så lave både læse og skriv på
> serveren, men ikke samtidig (i samme fil), og der kræves kun to
> objecter.

Det er som det skal og bør være, lad være med at lave for meget om.

> Jeg er slut, tror jeg, hjernekapaciteten er på nul. Det må blive i
> morgen.

Du har nok været træt, du er kommet til at skrive:
document.getElementById('chatbox').innerHTML = req.responseText;
meddelsesstatus = reqsu.getResponseHeader('Last-Modified');
document.getElementById('chatbox').innerHTML = req.responseText;
Du skal nok fjerne den ene opdatering af innerhtml, så der ikke kommer for
meget flimmer på skærmen.

Men på et andet tidspunkt har du *ikke* været træt.
I det store hele har jeg ikke kunnet se din chat. I min gamle Konqueror flød
teksten fra 'chatbox' ned ovenpå tekster, knapper, m.v.
I dag står det 'pludselig' som det skal med scrollbars og hele 'lortet'.
Jeg ved ikke hvad du har ændret, men det eneste jeg kan tænke er:
Rune - han *kan* squ det der html-lort.

Ok - næsten perfekt - der er lige noget med margen/padding og em. Men det
skyldes at Linux og MS ikke rigtig bruger samme fonte. MS har patent på
deres fonte, og kæmper selv guderne nok forgæves.

Men igen - koncentrer dig om brugeroplevelsen.
Hvis du har mistet overblikket over JS delen, vil jeg godt renovere/pynte
den for dig. (Nu har du lavet 'fodarbejdet').

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Du skal ikke lave noget om i strukturen. Det er som det skal være, og the
> best you will ever get.

Sorry, der var en ting jeg havde glemt.
I din send bruger du 'get' i stedet for 'post'.
Det er sådan set godt nok, men parameterne indgår i URI'en, og der er
begrænsninger på størrelsen af disse. Begrænsningen er browserspecifik, og
går fra 256 B til ca 4KB.
Du risikerer derfor at miste 'lange' meddelser.
Ændringen fra get til post involverer både clientside og serverside.
På serverside skal du ændre til at bruge Request.form.
Clientside skal du ændre i din DoSend.
Jeg kan i sagens natur ikke teste, så det bliver ''out of the head'.
reqs.open( 'get', 'shoutbox_update.asp?' + ptext , true);
æmdres til
reqs.open( 'post', 'shoutbox_update.asp' , true);
Og så skal vi lige fortælle at body er url encoded ved at tilføje:
reqs.setRequestHeader( 'Content-Type','application/x-www-form-urlencoded');
Og
reqs.send ( null); /* reqs.send( 'ptext'); */
ændres til
reqs.send( 'ptext');

Hvis du har prøvet det før, og det ikke virkede, er det fordi du har manglet
Content-Type headeren. Det er *den*, der fortæller IIS(Og andre), at den
skal udpakke variable og gøre dem tilgæmgelig i request.form (eller lign i
PHP).

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Stig Johansen wrote:
>
>> Du skal ikke lave noget om i strukturen. Det er som det skal være, og the
>> best you will ever get.
>
> Sorry, der var en ting jeg havde glemt.
> I din send bruger du 'get' i stedet for 'post'.
> Det er sådan set godt nok, men parameterne indgår i URI'en, og der er
> begrænsninger på størrelsen af disse. Begrænsningen er browserspecifik, og
> går fra 256 B til ca 4KB.
> Du risikerer derfor at miste 'lange' meddelser.
> Ændringen fra get til post involverer både clientside og serverside.
> På serverside skal du ændre til at bruge Request.form.
> Clientside skal du ændre i din DoSend.
> Jeg kan i sagens natur ikke teste, så det bliver ''out of the head'.
> reqs.open( 'get', 'shoutbox_update.asp?' + ptext , true);
> æmdres til
> reqs.open( 'post', 'shoutbox_update.asp' , true);
> Og så skal vi lige fortælle at body er url encoded ved at tilføje:
> reqs.setRequestHeader(
> 'Content-Type','application/x-www-form-urlencoded');
> Og
> reqs.send ( null); /* reqs.send( 'ptext'); */
> ændres til
> reqs.send( 'ptext');
>
> Hvis du har prøvet det før, og det ikke virkede, er det fordi du har
> manglet Content-Type headeren. Det er *den*, der fortæller IIS(Og andre),
> at den skal udpakke variable og gøre dem tilgæmgelig i request.form (eller
> lign i PHP).

Damn - hvorfor er der ikke syntax highlighting på min newsreader?
reqs.send( 'ptext'); skal ikke i 'er, så overfører man teksten ptext i
stedet for indholdet. Det skulle være reqs.send(ptext);

Jeg startede med at lave en lille form til testformål, den har jeg lagt på
din chat.

Den kan man bruge til at skifte mellem get og post, indtil _serverdelen_
virker.

Data bliver ikke opdateret med en post, men formålet var at fremprovokere en
200 OK.

Jeg tog så en lokal kopi af din side, og rettede til jfr. ovenstående.
Et kig på trace - hvad f* der står ptext i bodydelen, klaske mig selv på
panden fordi jeg ikke så det.

Jeg afprøvede det så med min Konqueror, men uanset hvad h* jeg gjorde, så
lagde den en blank ind mellem Content-Type headeren og den automatisk
genererede Content-Length header. Det resulterede i en 411 Length required.

Over på Win+FF, her får jeg en JS error pga sikkerhed, det gider jeg ikke
rette(fjerne).

Fat i den der IE slambert, for at teste. Her får jeg en 200 OK.

Observerer at der er lidt forskel på store og små bogstaver, tilbage til
Konqueror.

Stadig blank linie, så det er 100% en fejl i min Konqueror.
Prøver selv at lægge en Content-Length ind for at se hvad der sker.
Stadig en blank linie og nu 2 Content-Lenhgth headere - MEN nu forstår _din_
IIS det (200 OK).

Send delen ser nu sådan ud:
reqs.open( 'post','http://runejensen.dk/tips/ajax/shoutbox_update.asp' ,true);
reqs.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
reqs.setRequestHeader("Content-Length", ptext.length);
/* reqs.setRequestHeader("Connection", "close"); */
/* reqs.send(parameters); */
......... }
reqs.send(ptext);
// reqs.send ( null);

Hvorvidt det er en god ide med den ekstra Content-Length skal jeg ikke kunne
sige. Den får _min_ Konqueror til at virke mod _din_ IIS, men den kan
ligeså godt give støj i andre kombinationer af browsere/servere.

--
Med venlig hilsen
Stig Johansen

---

On 6 Jan., 06:37, Stig Johansen <stig_johansen_it_at_=(@)hotmail.com>
wrote:
> Rune Jensen wrote:

> > Jeg overvejer, om man kan slå den sammen med timeren, som opdaterer
> > users online, og så fjerne hentusers. Fordelen er jo, at det hele
> > foregår serverside i ét hug. Dvs.
>
> Nej, nej - lad endelig være med det, nu du har fat i den 'lange' ende.
> Jeg kunne godt for lang tid siden have givet dig 'facitlisten', men det
> lærer man normalt ikke så meget af.

Ok, så lader jeg være. Problemet var nu mere den del, som skal tjekke,
om brugere skal fjernes. Måske skal jeg lave den del som en ASP, så?
Altså så den ikke henter selve text-filen, men laver en send på ASP
brugeropdatering, hvor ASPen sender brugerne - så vil det jo også
kunne formateres pænt? Vil det skabe problemer?

> Jeg gav dig følgende hint:> Jeg har testet et forslag til nogle rettelser.
>
> Det skulle fortolkes som:
> Jeg har *testet* et forslag til nogle rettelser, ved at tilrette en lokal
> kopi af *din* side (as in afprøvet og virker).

Jah, man får nu mange mærkelige idéer, når det bliver sent. Så det jeg
lavede var nok mere en brainstorming

> > Der skal så sendes en request om send ved tryk på "send" knappen.
>
> Måske, men der er mere en mental beslutning.
> Som der er nu lever meddelserne 'sit eget liv', og det vil fungere perfekt..
> Det spørgemål du skal stille dig, og jeg mener du, for det er dit system er:
> Når en bruger har sendt en meddelse, skal hans egen (og nye) meddelse dukke
> op 'straks' eller kan den vente til næste 'poll' af meddelser?
> Vi taler *brugeroplevelsen*. Personligt ville jeg nok ikke opdage om den
> kommer 'straks' eller om 1-2 sekunder. Men igen, det er din beslutning.

Nej, det er fint nok. Der er ingen grund til at lave det mere
avanceret end nødvendigt. I hvert fald ikke foreløbigt, hvor det
stadig er forholdsvist basic. Ville du så foreslå send i forb. med
hent af message?

> > Problemet er stadig, om der konfliktes, men problemet ser mindre ud.
>
> Der er en _risiko_ for konflikt. Men det er en kombination af om en bruger
> tilfældigvis trykker send samtidig med der er en hent i gang.
> Løsningen er ligetil, men det afhænger af din beslutning af ovenstående.

Hmmm. Den må jeg lige tænke over. For hvis der er mere end én bruger,
kan man jo ikke forlade sig på check på én client?

> Du skal ikke lave noget om i strukturen. Det er som det skal være, og the
> best you will ever get.
> Det du kunne gøre er at samle de funktioner der hører sammen, og give dem
> lidt mere sigende navne. Eks. 'nrugertimeout' i stedet for 'timedcount2'
> osv.

DET kan jeg til gengæld finde ud af

> Du har nok været træt, du er kommet til at skrive:
>         document.getElementById('chatbox').innerHTML = req.responseText;
>         meddelsesstatus = reqsu.getResponseHeader('Last-Modified');
>         document.getElementById('chatbox').innerHTML = req.responseText;
> Du skal nok fjerne den ene opdatering af innerhtml, så der ikke kommer for
> meget flimmer på skærmen.

Det virkede slet ikke i IE med ovenstående før den ekstra linje blev
fjernet...

> Men på et andet tidspunkt har du *ikke* været træt.
> I det store hele har jeg ikke kunnet se din chat. I min gamle Konqueror flød
> teksten fra 'chatbox' ned ovenpå tekster, knapper, m.v.
> I dag står det 'pludselig' som det skal med scrollbars og hele 'lortet'.

To ting her:

Det første er, at der var fejl i CSSen. Jeg havde brugt overflow-x og -
y. Da det blev rettet, virkede det _tilsyneladende_ men...

InnerHTML er så vidt jeg har kunnet finde information, ikke standard,
hvorfor visse broewsere kan have problemer med den. Jeg overvejede en
lidt avanceret løsning (Det hedder vidst DOM), men _hvis_ det virker
med korrekt CSS, så... vil jeg lave den mere avancerede løning senere.

> Ok - næsten perfekt - der er lige noget med margen/padding og em. Men det
> skyldes at Linux og MS ikke rigtig bruger samme fonte. MS har patent på
> deres fonte, og kæmper selv guderne nok forgæves.

Vil det virke med en standard-font? Men er der ikke allerede en
standard-font? Må jeg lige tjekke

> Men igen - koncentrer dig om brugeroplevelsen.
> Hvis du har mistet overblikket over JS delen, vil jeg godt renovere/pynte
> den for dig. (Nu har du lavet 'fodarbejdet').

Pænt af dig. Og iøvrigt også Birger, at i har taget jer tiden, mener
jeg. Foreløbig har jeg sådan set forstået synkron/asynkron, samt de
mere simple ting. Faktisk forstod jeg også nærmest med det samme da du
skrev omkring statisk/dynamisk filer, selvom jeg nok skal læse op på
ASP-delen. Det, jeg mangler indsigt i er nok det med timerne, og så
hvordan man undgår konflikt. Jeg kan heller ikke helt se, hvordan man
kan opdatere brugerne uden yderligere en slags "send", altså kald af
en ASP. For man kan tjekke brugere online i den nuværende "send", men
så vil man jo også først få at vide den person, man skriver til er off-
line, når man har skrevet

Men det var måske det, du mente, da du skrev, at der skulle bruges
Custom Header? Jeg kan lave et forsøg med det - burde jo ikke ødelægge
opsætningen og koden som den er, mere en ændring af hentBrugere til en
asp i stedet for en .txt. Så vidt jeg kan se. Hmmm. Kan godt være, jeg
flagrer lidt, men der er også ret mange ting at holde styr på

MVH
Rune Jensen

---

Rune Jensen wrote:

> Ok, så lader jeg være. Problemet var nu mere den del, som skal tjekke,
> om brugere skal fjernes. Måske skal jeg lave den del som en ASP, så?

Nu begynder det at dæmre - Vi taler nok lidt forbi hinanden.
Jeg taler udelukkende om visning af den til enhver tid 'aktive' brugerliste.
Det foregår 100% clientside, da der ikke er mulighed for callback fra server
til klient.

Problemet med at en bruger 'logger af', og dermed fjernes, er noget helt
andet, og skal løses 100% serverside.
Problemstillinger er, at medmindre brugeren udfører en logout-funktion, har
serveren ikke en kinamands chance for at vide om brugeren stadig 'er på'.
(En af ulemperne med stateless protokoller).
En af mulighederne er at etablere en 'session'. Det foregår typisk ved at
tilknytte nogle værdier på serveren til en cookie.
(Jeg skriver det på den her måde foir at beskrive funktionaliteten, og ikke
ASP-specifikt)
Serverne har så typisk en timeout værdi, der benyttes til noget a.la.
'Hvis brugeren ikke har været aktiv i xx minutter, så er han nok
forsvundet'.

Den er enormt svær, fordi de 'langsomme' læsere risikerer at blive 'logget'
af hvis timeout er for lille.
Omvendt hvis den er for lang, risikerer man at sidde og 'chatte' med en
masse brugere, der forlængst er forsvundet.

En anden metode kunne være at forsøge at fange en event, når man 'forlader'
siden. Men hvis brugeren blot lukker for browseren, bliver der ikke (tror
jeg) fyret nogen event af.

Hvis du vil have størst mulig integritet i din 'brygere online', vil jeg
anbefale dig at implementere alle 3 metode, ud fra devicen 'hvad den ene
ikke fanger, gør den anden'.
Altså implementere:
1) En bruger logout funktion (i håb om klik)
2) Forsøge at fange en event ved forsvinden (fanger nogle af dem der ikke
klikke sig ud)
3) En session timeout, der fanger 'resten'.

> Altså så den ikke henter selve text-filen, men laver en send på ASP
> brugeropdatering, hvor ASPen sender brugerne - så vil det jo også
> kunne formateres pænt? Vil det skabe problemer?

Jeg er ikke sikker på jeg forstår hvad du mener med 'brugeropdatering'?

>> Måske, men der er mere en mental beslutning.
>> Som der er nu lever meddelserne 'sit eget liv', og det vil fungere
>> perfekt. Det spørgemål du skal stille dig, og jeg mener du, for det er
>> dit system er: Når en bruger har sendt en meddelse, skal hans egen (og
>> nye) meddelse dukke op 'straks' eller kan den vente til næste 'poll' af
>> meddelser? Vi taler *brugeroplevelsen*. Personligt ville jeg nok ikke
>> opdage om den kommer 'straks' eller om 1-2 sekunder. Men igen, det er din
>> beslutning.
>
> Nej, det er fint nok. Der er ingen grund til at lave det mere
> avanceret end nødvendigt. I hvert fald ikke foreløbigt, hvor det
> stadig er forholdsvist basic. Ville du så foreslå send i forb. med
> hent af message?

Nej, jeg vil foreslå, at du lader det være som det er.

>> Der er en _risiko_ for konflikt. Men det er en kombination af om en
>> bruger tilfældigvis trykker send samtidig med der er en hent i gang.
>> Løsningen er ligetil, men det afhænger af din beslutning af ovenstående.
>
> Hmmm. Den må jeg lige tænke over. For hvis der er mere end én bruger,
> kan man jo ikke forlade sig på check på én client?

Her taler vi også om 2 ting.
Den risiko jeg omtaler er udelukkende på brugerens maskine. Risikoen gå på,
at hvis han trykker send mens der er en hent i gang på _hans_ maskine, vil
han få en eller anden JS fejl. Det er ikke sikkert det nogensinde vil ske i
det virkelige liv, men personligt bryder jeg mig ikke om den slags latente
fejl.

Det lyder som om du tænker på konflikter på serveren.
Her kan du hente ligeså mange samtidige meddelelser(readonly) som din server
kan trække.
Den risiko du har på serveren er hvis 2 _brugere_ trykker send på samme tid.
Den skal du styre 100% serverside.
Hvis du bruger databaser er det indbygget i databasen.
Hvis du opdaterer en fil, skal du lave ca. pseudo:
1) Lås fil med 1 writer + multiple readers
2) Opdater filen
3) Lås filen op igen.

ad 1: Jeg kender ikke syntax og konstanter i ASP.

>> Du har nok været træt, du er kommet til at skrive:
>> document.getElementById('chatbox').innerHTML = req.responseText;
>> meddelsesstatus = reqsu.getResponseHeader('Last-Modified');
>> document.getElementById('chatbox').innerHTML = req.responseText;
>> Du skal nok fjerne den ene opdatering af innerhtml, så der ikke kommer
>> for meget flimmer på skærmen.
>
> Det virkede slet ikke i IE med ovenstående før den ekstra linje blev
> fjernet...

Her har du tabt mig. Der er 2 identiske linier.
Mener du tilføjet eller fjernet?
Eller mener du at IE skal have det samme at vide 2 gange for at virke?

> InnerHTML er så vidt jeg har kunnet finde information, ikke standard,
> hvorfor visse broewsere kan have problemer med den. Jeg overvejede en
> lidt avanceret løsning (Det hedder vidst DOM), men _hvis_ det virker
> med korrekt CSS, så... vil jeg lave den mere avancerede løning senere.

InnerHTML er en del af (browserens) DOM, men du har ret, efter en hurtig
søgning på Google, ser det ikke ud som om det er en del af standard DOM.

Hmm.. nærlæser lige
<http://xml.coverpages.org/dom.html>
Faldt over denne her sætning:
.........
Both browsers support a basic set of the W3C's methods and attributes, as
well as the innerHTML property (not included in the W3C DOM, but included
by popular demand).
.........
Med hensyn til innerHTML ser det ud som om man skal forlade sig på
definitionen af 'popular demand'.

>> Ok - næsten perfekt - der er lige noget med margen/padding og em. Men det
>> skyldes at Linux og MS ikke rigtig bruger samme fonte. MS har patent på
>> deres fonte, og kæmper selv guderne nok forgæves.
>
> Vil det virke med en standard-font? Men er der ikke allerede en
> standard-font? Må jeg lige tjekke

Det virker, det er bare noget med at en 'MS' em ikke er det samme som en
'Linux' em.
Det er heller ikke sikkert, der er em'erne. der gør det.
Det er kun den del med tekstfelter, brugerliste m.v., der ligger ovenpå
noget blåt og nogle rammer, altså det ser ud som om det er forskudt.
Jeg er ikke god nok til at finde ud af om det er margins/paddings em'er
eller default 0 i Konqueror's css eller lign.

> Jeg kan heller ikke helt se, hvordan man
> kan opdatere brugerne uden yderligere en slags "send", altså kald af
> en ASP. For man kan tjekke brugere online i den nuværende "send", men
> så vil man jo også først få at vide den person, man skriver til er off-
> line, når man har skrevet

Den har vi været inde over.

> Men det var måske det, du mente, da du skrev, at der skulle bruges
> Custom Header?

Ikke helt. Tanken med Custom headeren var at man vistnok kan lave nogle
serverglobale variable i ASP (global.asa?)
Tanke var at man holder 'versionsnummeret' i sådan en, og ved en request
starter man med at sammenligne 'versionerne'.
Hvis de ikke er forskellige kan man nøjes med at sende headeren tilbage uden
at belaste serveren yderligere (+båndbredde).

--
Med venlig hilsen
Stig Johansen

---

On 7 Jan., 07:02, Stig Johansen <stig_johansen_it_at_=(@)hotmail.com>
wrote:
> Stig Johansen wrote:
> Damn - hvorfor er der ikke syntax highlighting på min newsreader?
> reqs.send( 'ptext'); skal ikke i 'er, så overfører man teksten ptext i
> stedet for indholdet. Det skulle være reqs.send(ptext);

Den burde jeg faktisk have set, nu jeg har blæret mig sådan med min
viden. Nu er jeg ikke så kry mere hvad angår min viden om Javascript.
Prøvede ret så mange gange med post, men _ingenting_ kom frem bortset
fra afsendelsestidspunktet


> Send delen ser nu sådan ud:
>    reqs.open( 'post','http://runejensen.dk/tips/ajax/shoutbox_update.asp',true);
>    reqs.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
>    reqs.setRequestHeader("Content-Length", ptext.length);
>    /* reqs.setRequestHeader("Connection", "close"); */
>    /* reqs.send(parameters); */
> ........                        }
>    reqs.send(ptext);
> //  reqs.send ( null);
>
> Hvorvidt det er en god ide med den ekstra Content-Length skal jeg ikke kunne
> sige. Den får _min_ Konqueror til at virke mod _din_ IIS, men den kan
> ligeså godt give støj i andre kombinationer af browsere/servere.

Nej, den ser ud til at virke. Måske bemærkede du, jeg faktisk har
leget lidt med content.lenght. Dette er ikke fordi jeg faktisk aner,
hvad det betyder, eller hvordan det bruges (selvom jeg har nogle vage
idéer), men fordi jeg faldt over denne side

http://www.captain.at/howto-ajax-form-post-request.php

hvor det bliver brugt i en lign. situation med min.


Jeg prøver lige at implementere den rigtige form af ptext og så
ovenstående.

Og tak for forsøget. Det hjalp

PS. Og så har jeg en kode i gang på send-ASPen, hvor man med en
bestemt text-kombination kan logge sin bruger af. Ret interessant, om
det virker, men der burde ikke være konflikt

PPS. Jeg har problemer med absolut sti. Det skal klare på serversiden,
men jeg er ikke lige helt klar over hvordan. Hint: www er et
subdomæne, så der er forskel på absolut sti med og uden..


MVH
Rune Jensen

---

Rune Jensen wrote:

> Nej, den ser ud til at virke. Måske bemærkede du, jeg faktisk har
> leget lidt med content.lenght.

Jo, det fremgik tydeligt af din source.

> Dette er ikke fordi jeg faktisk aner,
> hvad det betyder, eller hvordan det bruges (selvom jeg har nogle vage
> idéer), men fordi jeg faldt over denne side
> http://www.captain.at/howto-ajax-form-post-request.php
>
> hvor det bliver brugt i en lign. situation med min.

Han ved heller ikke hvordan det bruges.
Content-Length er en indbygget header, der automatisk bygges ud fra body
delen af HTTP requesten.
I 'gamle' dage bestod en HTTP request af
Headere
<blank linie>
Body part
<blank linie>
<blank linie>

dvs størrelsen af body part er ukendt indtil man rammer to tomme linier.
Content-Length er simpelthen bare antallet af bytes i body part, så serveren
ved 'hvad der kommer'.

At jeg 'geninførte' den i dit script var simpelthen for at 'snyde' min
Konqueror, og ikke noget man bør gøre generelt.

> PPS. Jeg har problemer med absolut sti. Det skal klare på serversiden,
> men jeg er ikke lige helt klar over hvordan. Hint: www er et
> subdomæne, så der er forskel på absolut sti med og uden..

Yep, der er en opsætning i DNS, og du skal ikke bruge absolutte URI'er.

Det er en reminisens fra første gang jeg ville prøve at lave en lokal kopi.
Nu må du ikke blive sur, men det var fordi du havde noget i webroot, og
noget relativt, så jeg syntes bare (dengang) jeg måtte 'gætte mig frem'.

--
Med venlig hilsen
Stig Johansen

---

On 7 Jan., 19:28, Stig Johansen <stig_johansen_it_at_=(@)hotmail.com>
wrote:
> Rune Jensen wrote:

> >http://www.captain.at/howto-ajax-form-post-request.php
>
> > hvor det bliver brugt i en lign. situation med min.
>
> Han ved heller ikke hvordan det bruges.
> Content-Length er en indbygget header, der automatisk bygges ud fra body
> delen af HTTP requesten.
> I 'gamle' dage bestod en HTTP request af
> Headere
> <blank linie>
> Body part
> <blank linie>
> <blank linie>
>
> dvs størrelsen af body part er ukendt indtil man rammer to tomme linier.
> Content-Length er simpelthen bare antallet af bytes i body part, så serveren
> ved 'hvad der kommer'.
>
> At jeg 'geninførte' den i dit script var simpelthen for at 'snyde' min
> Konqueror, og ikke noget man bør gøre generelt.

Meget rart at vide. Men det gør scriptet mere kompatibelt at det er
der?

> > PPS. Jeg har problemer med absolut sti. Det skal klare på serversiden,
> > men jeg er ikke lige helt klar over hvordan. Hint: www er et
> > subdomæne, så der er forskel på absolut sti med og uden..
>
> Yep, der er en opsætning i DNS, og du skal ikke bruge absolutte URI'er.

Lyderogså godt, så kan jeg på et tidspunkt fjerne den ekstra ASP

> Det er en reminisens fra første gang jeg ville prøve at lave en lokal kopi.
> Nu må du ikke blive sur, men det var fordi du havde noget i webroot, og
> noget relativt, så jeg syntes bare (dengang) jeg måtte 'gætte mig frem'.

Det krævede lidt tænkearbejde at få den til at acceptere absolutte
stier på både www og uden www i javascript, men det gik endda. Jeg gik
bare forkert ind på det, ellers havde jeg løst det hurtigere, for det
burde være banalt, har lavet sådan noget før.

PS. Man kan logge off ved at skrive [log off] for sig selv i en ny
linje. Jeg er overrasket. For det virkede i første hug skrevet udfra
hukommelsen (men ASPen er heller ikke heeelt pæn endnu). Regner med at
lave en knap, som kan trigge kommandoen. Så er der kun "timer til log
off"-problemet, som jeg ikke helt er klar over, hvordan løses. Altså
at hver gang man sender en meddelelse skal man have et vist tidsrums
ekstra tid, før man automatisk kobles af.

Nu sker så det, når man looger af, at alt om ens identitet fjernes,
undtagen deletegnene, dvs. ; -tegnet, som skiller dataene. Den kigger
jeg på.


MVH
Rune Jensen