Jututoa tehniline kirjeldus. 

Igasugu andmevahetus arvutite vahel taandub lõppkokkuvõttes kahendkujul
baitide edastamiseks, kuid pealisehitus andmeedastusprotokollide ning
kasutajakeskkonna näol võib küllaltki erinev olla. Ülekantavaks materjaliks
võib olla kõik, mida vähegi õnnestub sümbolite abil kirjeldada, kuid
enamasti puudub vajadus või tehnilised vahendid kõige mõeldava edastamiseks. 
	Suuremate (enamasti staatiliste) andmete edastamiseks kasutatakse enam www ja ftp võimalusi. Sõnumite saatmiseks kirju ja talk-programmi taolisi jutustusvahendeid, suurema hulga kasutajate puhul uudisgruppe, postiloendeid, (külalis)raamatuid ja jututube(konverentsiruume). Muidugi on veel igasugu võimalusi teabe edastamiseks nagu näiteks Netmeetingu abil ühele programmile mitme kasutaja poolt saadetavad teated või lausa videokonverents.
	Lisaks varem levinud telneti jututubadele muutusid tasapisi ka mõned külalisraamatud jututubade suunas. Kui neisse hakati nii tihedasti kirjutama, et seda võis lausa reaalajas suhtlemiseks pidada, siis  mõeldi välja (võeti kasutusele) programmijupike, mis iseenesest akna sisu mingi aja tagant uuendas. Et saaks korraga kirjutada ning toimuvat jälgida, selleks löödi lehekülg raamidesse. Teksti pikenedes ning aeglasema ühenduse korral kippus taaslaadimise aeg üha pikemaks minema. Probleeme  tekitas see eriti nende lahenduste korral, kus uued teated lõppu läksid. Siis sai teiste vastukaja alles suure hilinemisega teada. Selleks puhuks mõeldi võimalus teadeteaknasse andmete saatmiseks pideva voona. Sisuliselt tähendas see cgi-programmi, mis pidevalt tasapisi teksti saatis vastavalt sellele, kuidas seda kasutajatelt tuli. Et teksti lõpp kasutajale näha oleks, selleks saadetakse sellise teksti sisse mõne rea tagant väikesi java-skriptikesi käsuga scroll, mis siis lehekülge edasi kerivad. 
	Sellised külalisraamatu moodi jututoad töötavad mis tahes graafilisel raamidega brauseril ning suudavad rahuldada enamiku tavateksti kaudu suhtlemise vajadusi. Kasutajate eristamiseks saab mängida piltide, värvide ja šriftidega, sellest tulenevalt saab rahuldavalt edastada ka nii läti- kui venekeelset teksti. Ka jututoa arhiiv on sellisel juhul loetaval kujul pea automaatselt olemas. Erikäsklusi edastatakse enamikes sellistes programmides käsurealt. Nad lihtsalt algavad punkti või jagamismärgiga. Põhimõtteliselt aga on võimalik selle jaoks HTML teksti sisse kirjutada javaskripti programmikesed, mis laseksid kasutajal käske (näiteks privaatteade, väljameldimine) valida ilma, et ta nende üle pead vaevama või neid helbist otsima peaks. Aga hoolimata väljamõeldud vidinatest saab HTML-i javaskripti ning cgi abil ikkagi põhiliselt teksti edastada. 

	Praegusel juhul valisin edastamiseks pildi ja teksti.  Ladina
tähestikus tekstiga peaks õnnestuma vastaskasutajale üle kanda enamus
vajaminevast infost. Ülejäänu peaks saama joonistada ekraanil olevale
tahvlile ning siis pildina üle kanda. 
	Püüdsin koostada säärase sidepidamisvahendi, mida oleks lihtne
kasutada ning ka lihtne arvutisse paigaldada. Ülekande võrguks valisin
Interneti, programmeerimiskeeleks java ning programmi panin tööle
brauseriekraanil appletina. Internet peaks vahendusvõrguks sobima seetõttu,
et tema abil saab sidet pidada nii lühikese kui  pika maa tagant programmi
poolt vaadates samadel tingimustel. Ikka sobib arvuti aadressiks IP number
ehk masina interneti aadress. Java keel on selline programmeerimiskeel,
mille abil kirjutatud programmid töötavad ilma täiendava muutmiseta igas
operatsioonisüsteemis, mille jaoks on loodud java virtuaalmasina emulaator
(vastav programm, mille abil saab kompileeritud java klasse käivitada). Nii
saab valmis kirjutatud serveri poolset programmi kasutada nii linux-i
(milles ma ta lõin), Unixi kui ka Windowsi serveris. Sama kehtib ka
kasutajaliideste kohta. Teda saab kasutada mis tahes platvormilt, kus töötab
javat toetav brauser. Ning programmi "installeerimiseks" masinasse tuleb
kasutajal vaid tippida aadressireale suhtlusvahendit sisaldava lehekülje
aadress või vajutada viidete leheküljelt sobivale viitele. IRC või mõne muu
säärase süsteemi puhul tuleks sidevahendi programm enne käivitamist kasutaja
arvutisse salvestada. See muudab programmi brauserist sõltumatuks ning lisab
talle võimalusi kettalt lugemise ning sinna kirjutamise näol, kuid lisab
kasutajale kohustuse arvutis programmi esmakordsel kasutamisel programm
arvutisse kopeerida.  	
	Jututoa kirjutamiseks kasutasin java versiooni 1.0.2. See on Java esimese versiooni 1.0 kõige viimistletum variant. Kirjutama hakates kaalusin pikalt, kas kasutada versiooni 1.0 või 1.1. 1998. aasta lõpus valminud 1.2-hest polnud kirjutamise alustades veel suurt midagi kuulda. Enamasti pole programmeerimiskeelte versioonidel kuigi suurt vahet ning ka java puhul on põhikonstruktsioonid (plokid, tsüklid, valikud) eri versioonides sarnased. Kuid kuna tegemist on suhteliselt uue programmeerimiskeelega, mis erinevalt tavalistest kompileeritavatest või transleeritavatest keeltest püüab olla emuleeritav kompileeritud programmikoodiga keel, siis tuleb keele loojatel teha palju uut tööd ning erinevused versioonide vahel on täiesti märgatavad. Seda eriti programmeerimise "uutes" valdkondades - võrkude ning teadete töötlemise osas. Mõlemat osa aga tuleb kasutajale reageerivas ning võrgu abil andmeid vahetavas keeles kasutada. 
	1997. a. lõpul olid Eestis valitsevateks brauseriteks Netscape Navigator 2, 3 ja Gold ning Internet Explorer 3. Nende levik on suur ka aasta hiljem ning nemad toetavad vaid java 1.0 applette. Java 1.0.2 kompilaator töötas suhteliselt veatult võrreldes arendatavate 1.1 kompilaatoritega, sest teda oli võrratult enam katsetatud ja testitud. Samuti olin ise enam tuttav vanema versiooniga 1.0, järgmise versiooni kohta olin vaid näiteid vaadanud. Lisaks sellele oli kuulda, et 1.1 ei jää tõenäoliselt kuigi kaua valitsevaks versiooniks, sest juba arutati kõvasti järgmise ning ülejärgmisegi versiooni üle. Nendele eeldustele toetudes otsustasin suhtlusvahendi luua java 1.0.2 abil, et teda saaks kasutada suur osa arvutiomanikke ning et teda oleks mugav kirjutada ja parandada. 
	Ligi kaks nädalat otsisin näiteid, millele toetudes saaks oma programmi luua ning millega võrrelda. Enamik näidetest, mis end jututoa (chat) all reklaamisid lihtsalt ei töötanud. Mõned ei kompileerunud ning mõned andsid kasutamise ajal veateateid. Mõned ülespandud näited ei andnud küll vigu, kuid lihtsalt ei töötanud. Leidsin mõned kümned appletite abil töötavad jututoad, kuid nende kohta polnud lähtekoodi saada. Polnud muud kui java manuaalide (mis on suhteliselt korralikud) kallale asuda. Sealt sain vähemalt ideele pihta ning lõpuks poolkogemata leidsin Soomest ka ühe töötava ning lähtetekstiga varustatud näite.
 
	Andmete edastamiseks kasutatan klient-server mudelit. Kasutajate ekraanil töötavad appletid on ühenduses serveriga arvuti portide vahele loodud "soketi" abil. Selle kaudu saavad programmid arvuti vahel baitidena andmeid saata.	Serveripoolne programm "püüab kinni" serveri vastava pordiga ühenduse võtja ning käivitab java klassi (praegusel juhul SingleServer) eksemplari, kes hakkab konkreetse ühenduses olijaga sidet pidama. See objekt võtab vastu kasutajapoolselt programmilt tuleva info, töötleb seda ning saadab soketi kaudu serveri poolse info. Tähtsamad teated (serveriprogrammi käivitamise aeg, uue kasutaja juurdetulek, saadetud tekst) kirjutatakse logifaili. Uue kasutaja saabumisel, juhul kui server on võimeline teda vastu võtma, salvestatakse tema andmed staatilistesse muutujatesse, mille sisu poole saavad pöörduda kõik serveripoolse klassi initsialiseeritud objektid. Seejärel väljastatakse uuele kasutajale serveriprogrammi abil mälus seisvad teated, et uus kasutaja teaks, millised naabrid tal on ning millega need varem tegelenud on. (meetod dumphistory).
	Kasutajapoolne programm töötab brauseriekraanil ning võtab jällegi soketi kaudu ühenduse serveri vastava väratiga. Applettide turvatehnoloogiast tingituna saab applet ühendust pidada vaid selle serveriga, millest ka tema kood pärit on. Serveri poolt tulevate teadete järgi muudab kasutajakeskkond oma välimust ning edastab kasutajale teiste poolt edasi antavat teavet. 
	Eelkirjeldatud lõigud peaksid kehtima enamike mitmekasutajasüsteemide kohta. Edaspidine sõltub juba loodava rakenduse eesmärgist, temale esitatavatest nõuetest ning kasutada olevatest vaimsetest, tehnilistest ning ajalistest võimalustest. 
	Samale põhjale olen minagi teinud õige mitu realisatsiooni. Esimene - nagu ikka - kontrolliks, et süsteem ülepea töötab ning tema abil midagi võimalik ette võtta on. 	Selleks koostasin vaid serveripoolse programmi ning kasutaja sai sellega ühendust võtta telneti abil serveri vastavasse väratisse. Nii on kõige lihtsam kontrollida, mida serveripoolne programm väljastab, saab talle edastada teksti ning vaadata, kuidas ta sellele reageerib. Telneti jutukad töötavadki selle võimaluse abil ning mõni aasta tagasi olid nad valdavad ning nende abil sai enamik masinatevahelisi jutte peetud. Kui on vaja vaid andmeid edastada, piisab tekstiekraani graafilistest võimalustest ning kasutajapoolne töö piirdub vaid käskude ja andmete sümbolitena sisestamisega ning kasutajale tulevad andmed esituvad ka tähtede abil, siis piisab telneti akna poolt pakutavatest võimalustest. Mida lihtsam on programm, seda lihtsam on teda muuta töökindlaks. Sellisena töötavad praegugi (1998) mitmed programmid, kus eri kasutajatel eri masinate taga on vaja lugeda ning muuta ühes serveris asuvaid andmeid. Näiteks piletimüük või mõne pangakontori side keskusega. Kogu arvutamise ning andmetega muu manipuleerimise (salvestamise, lugemise, ... ) töö on jäetud serveri poolele ning kasutaja arvutis peab olema vaid programm serveriga andmete vahetamiseks. Sellisena on kasutaja asukoht vajaduse korral kergesti muudetav. Kui serveri poolne programm samuti tarvitab andmete vahetamiseks vaid üht või mõnda väratit ega kasuta muid interneti serverile harilikult külgepoogitud teenuseid (finger, httpd, ...), siis saab ka serveripoolse programmi käivitada suvalises Internetiga ühendatud IP nubrit omavas arvutis. Juhul, kui serverprogramm on kirjutatud keeles, mille jaoks leidub emulaator mitmes operatsioonisüsteemis(nt java, perl), siis võib serverprogrammi käivitada masinas, millel on neist operatsioonisüsteemidest milline tahes. 
	Telneti akna puuduseks on, et nii kirjutamine kui lugemine toimuvad kursori kohalt ekraanil ning kasutajal ei ole võimalik saabuvast tekstist sõltumatult oma teksti kirjutada. Jututubade puhul põhjustas see lausa omaette kirjutamisstiili, sest kirjutajal ei olnud võimalik pidevalt juurde tulevate uute teadete tõttu oma teksti näha ega seetõttu ka trükivigu parandada. Ta nägi oma teksti tervikuna vaid pärast ärasaatmist ning sai alles selle järel (ning võibolla veel pärast mitme muu kasutaja teadet) trükivea kohta veaparanduse saata. 
	Kui kasutaja masinasse luua programm, mis töötleks ning vahendaks võrgu kaudu edastatavaid andmeid, siis aitab ta telneti akna lihtsusest tingitud puudustest vabaneda. Lisaks sellele annab ta võimaluse osa arvutuslikku tööd teha kasutaja masinas, juhul kui see peaks vajalik olema. Nii saab näiteks andmeid saatmiseks krüpteerida või pakkida, ilma et kasutaja selle üle oma pead vaevama peaks. Kasutajapoolne programm võib olla nii tekstipõhine kui graafiline. Ta on arvutis nagu iga tavaline programm, lihtsalt ta võib andmeid lisaks klaviatuurile, kettale ja välisseadmetele ka võrku saata ning sealt saada. Sellise programmi kasutamiseks peab ta arvutisse kopeerima. 
	Kas kopeerimine probleemiks on, see sõltub programmi kasutamisest. Juhul kui kohalikus masinas käivitamisest tulenevad õigused annavad kasutajale märkimisväärselt võimalusi juurde, kui programmi maht on suur ning kui teda kasutatakse sageli ja pikemalt ühel töökohal on tõenäoliselt otstarbekas programm kohalikku masinasse kopeerida. Suur maht lihtsalt aeglustab igakordset kohalevedu ning koormab liine. Kui aga eelnevad tingimused olulisi eeliseid ei anna ning kasutaja soovib eri kasutuskohtadest jätkata tööd parasjagu kehtivast seisust (kas siis sealt, kus ta viimati oma tegemised pooleli jättis või arvestades vahepeal ka teiste tehtut), siis on kasulik vähemalt andmed hoida kõikjalt kättesaadavas serveris ning töö jätkamisel vajalik hulk nendest kasutuskoha juurde kopeerida. Selline korraldus peaks sobima, kui töötatakse piiratud hulga masinate taga. Näiteks kodus tööl ja koolis. Kui töötatakse sageli juhuslike masinate taga (kasvõi kooli arvutiklassis) ning sama programmi kasutajaid on suhteliselt vähe, nii et ei ole mõistlik kõikides neis arvutites programmi hoida, siis oleks kasulik võimalus ka programmi serveris hoida ning sealt vajaduse korral välja kutsuda.  Sellise võimaluse pakuvad näiteks java appletid, mille baasil minagi suhtlusvahendi lõin. 
	Proovisin mitmeid võimalusi. Kui tegemist on suurema hulga kasutajatega, kelle huvid grupeeruvad mingil viisil, siis toovad jututoas selgust toad ehk "kanalid", s.t. et kasutaja näeb vaid temaga samas toas olevate kasutajate juttu. Kui aga on tegemist suhtlusvahendiga mingi täpsemalt määratud ürituse jaoks, siis saab arvestada konkreetsete vajadustega, siis saab luua võimalusi konkreetsete probleemide jaoks ning keskkonda jälle muude üldiselt tavaliste võimaluste arvelt lihtsustada. 
	Konkreetseks ülesandeks oli mul vaja luua rakendusprogramm, mis võimaldaks kaugkoolituse teel õppida. Eeldasin, et tegemist on ühe õpetaja ning kuni nelja õppegrupiga. Arvasin, et rohkematega ei suuda õpetaja nagunii korraga tegelda ning ka ekraani peal läheks kitsaks. Siis ei saaks igale kasutaja(grupile) omaette tekstikasti eraldada, vaid peaks hakkama ühe kasti sees kasutajaid eristama. S.t. nagu tavalistes jutukates. Iga grupi jaoks omaette tekstikastil on nii eelised kui puudused. Kaasneb võimalus iga osaleva grupi juttu eraldi näha. Niimoodi saab pikemat juttu rahulikult kirjutada, ilma et teiste poolt tulnud teated jutule vahele tükiksid ning samuti et ei jääks kirjutamisel teiste jaoks nii pikka pausi, et tunduks, et osapool on juba masina tagant kadunud. Sellise moodusega saab ka õpetaja "loengut" järjest lugeda, ilma et kuulajate vahelepõiked ja küsimused tervikut segaks. Samas saab aga sellise võimaluse korral muretsemata vahele küsida ilma et kaaslaste häirimise pärast südametunnistuse piinu tunneks. Puuduseks on, et sellisel kirjutamisel jääb pärastpoole põgusalt teksti lugedes segaseks, kes mida varem ning kes hiljem ütles. Eraldi kastidesse panin kasutajad veel seepärast, et õpetaja saaks kergesti vajaduse korral ühele grupile teiste gruppide andmeid mitte näidata. Sellist võimalust sooviti näiteks kontrollimise või ülesannete lahedamise puhuks, kus tuleks hakkama saada kõrvalise abita. Muidugi oleks sedagi ju võimalik teha ka suure tekstiekraani korral. 
	
	Kasutaja ning serveri vahel liigutan andmeid stringidena. Need raiskavad küll erisümbolite puudmise tõttu ruumi, kuid selle eest on andmevahetus paremini kontrollitav.Lihtsustamiseks olen alustanud teksti sisaldavaid stringe t-ga, pilti transportivaid  stringe p-ga, k käsu ning a arhiivpildi jaoks. Teine täht(number) stringis määrab, kellelt saadetis tuli, kolmas näitab, kellele ta määratud on. Nii võib esimest nelja tähte nimetada n.ö. päiseks, andmed, juhul kui neid vastavas saadetises on, tulevad pärast seda.  Õpetaja numbriks on 0 (nagu ikka, hakatakse võimaluse korral arvutis numbreid lugema nullist, et esimene vahe kaotsi ei läheks), gruppidele kuuluvad 1-4 ning kõikidele kasutajatele määratud saadetist tähistab täht a(all). Päise üle ei pea kasutaja muret tundma, selle loob kasutajapoolne programm automaatselt. Käivitamise järgselt esimesel serveriga suhtlemisel saab kasutaja omale numbri. Kellele saata, sõltub kasutajast ja tema tegevusest. Teateid ning pilti saab õpetaja saata kõigile korraga ning igale eraldi. Õppegrupid saavad saata vaid kõigile. Ainukese käsuna saab õppegrupp end vaid välja logida, õpetajal on lisaks võimalus käsuga määrata, milline kasutaja keda näeb ning saab vajaduse korral kellegi ühenduse katkestada. 
	Teate või pildi päisele järgnevad andmed reisivad kohale koos päisega vastavalt sinna kirjutatud "aadressile", lisaks kirjutatakse pildid veel piltide logifaili, teated ja käsud teise logifaili. 
	Pildiarhiiv on selles programmis loodud vaid õpetaja jaoks. Põhiline eesmärk on tal saada üle appleti turvaprobleemist, mis ei luba kohaliku masina kettale salvestada ning seeasemel pakub võimaluse salvestada ette valmistatud pildid serverisse. Kuid see toob lisaväärtusena kaasa võimaluse, et õpetaja saab valmistada tundi ette sõltumata masinast mille taga ta istub. Arhiivi suuruseks panin kümme pilti, kuid seda numbrit tuleb võibolla võrguühenduse arenedes suurendada või pildi suuruse ning resolutsiooni suurenedes vähendada. Kuna väga pikkade stringide transport on vähemalt java 1.0 puhul veaohtlik (järgmistes versioonides on püütud seda parandada), siis jagan andmed tükkideks. Pildiarhiivi kasutaja arvutist serverisse saatmiseks saadan kõigepealt serverisse teate, et tuleb uus arhiivitäis pilte. Selle peale kustutab serveri programm tagavarakoopia faili ning muudab endise arhiivi tagavarakoopiaks. Siis kirjutab saabuvad pildid ükshaaval arhiivi. Arhiivi lugemiseks kasutaja arvutisse saadab kasutaja serverile teate, et soovib arhiivi koopiat enesele. Selle peale saadab server teate, et ta hakkab pilte saatma ning selle järel tulevad pildid. Piltide tulemise teate peale määrab kasutajapoolne programm, et esimene pilt tuleb mälupessa nr 0. Iga järgmine pilt läheb ühe võrra suuremasse pessa. 
	Et kasutajamasinates töötavate appletide vahel saaks andmeid vahetada, selleks peab neid serveripoolne programm vastu võtma ning edasi saatma. Et serveripoolne programm töötaks, peab selle keegi käima panema. Katsetamise ajal on lihtne. Programmeerija mellib (logib) end serverisse, käivitab serveripoolse programmi ning kasutajad saavadki suhelda. Pikema kasutamise puhul aga tekib raskusi: programmeerija ei taha pidevalt arvuti juures olla vaid selleks et teised saaksid omavahel juttu ajada. Ennast sisse mellitult arvuti juurde jätta ning ise minema minna pole ka viisakas ega turvaline. Keegi juhuslik arvuti taha pääsenu võib valede andmete kallale pääseda. Programmi käivitusõiguste valdajal on võimalus jätta programm tööle tahaplaanile ning ise väljuda. See annab võimaluse programm pikemaks käima jätta ilma, et keegi peaks tal pidevalt silma peal pidama. Kui aga mingil tehnilisel põhjusel programm "kinni jookseb" või lihsalt seiskub, sel juhul kasutajad enam suhelda ei saa. Seiskumisele olen avastanud mitmesuguseid põhjusi, neist muu hulgas ka seletamatuid. Levinumaks põhjuseks on programmis olev viga, mis mingis olukorras avaldub. Näiteks püütakse luua või kirjutada faili, milleks aga programmil õigusi pole. Juhul kui programmis pole korralikku veatöötlusosa, seiskab see programmi. Mõnikord on probleemiks mälumahu arvestamata jätmine, mõnikord pahatahtlikult või rumalalt kasutajalt saabuvad hiidsuured andmed. Vahel häirib süsteemide sobimatus. Java 1.0 ning mõne 1.1 intepretaatori korral olen avastanud, et serveripoolne programm katkestab töö soketist sisend- ja väljundvoo püüdmisel, juhul kui ühendust võtab täisekraanil (mitte raamis) töötav Netscape 4.0  lehe korduslaadmisel (reload). Mitte ei genereerita viga nagu oleks ootuspärane, vaid programm lihtsalt seiskub. Selleks puhuks olen ühendust võtvad appletid enamjaolt raamidesse paigutanud. Samuti on harva kasutamise korral mõtet programm seisata ning vajadusel uuesti käivitada. Kuid ja aastaid serveris kasutajat ootavad töötavad programmid lihtsalt raiskavad serveri ressursse. Selleks lõin võimaluse käivitada serveripoolne programm brauseri kaudu cgi-programmi abil. Nii saab õpetaja enne tunni algust suhtlusvahendi käivitada ning pärast vajaduse korral sulgeda. Sedaviisi saab serveripoolse programmi käivitada ka näiteks siis, kui programm on serveri alglaadimise tõttu seiskunud. 
	Pidevalt aitab programmi käigus hoida crontab. See on säärane programm, mis suudab ettemääratud ajal käivitada miski ettemääratud käsu/programmi. Oma jututoa käigushoidmiseks kasutasin esmalt võimalust, kus crontab käivitas igal minutil serveripoolse programmi. Juhul, kui üks eksemplar töötas, lõpetas järgmine varsti oma töö, sest serveri port oli hõivatud. Süsteemiadministraatorilt aga sain selleks otstarbeks parema mooduse. Ta pakkus ühe shelli skripti, mis kontrollis, kas serveripoolne jututoa programm töötab või mitte. Ja vaid juhul, kui tema protsessi pole protsessitabelis, ta käivitab serveripoolse ühendusepidaja. 
	Nii õpetaja kui õpilaste (gruppide) jaoks loodud programm on applet (klassi java.applet.Applet alamklass ehk järglane) ning käivitub brauseri ekraanil. Ta kasutab eelnevalt valmistatud komponente. Tekstikast, nupp ja märgend on juba java oma klasside hulgas olemas. Tahvli kirjutasin juurde. 
	Appleti klassi algul on muutujate (ja kasutatavate klasside hetkeeksemplaride) kirjeldused vajadusel koos initsialiseerimiskonstruktoritega. protseduur init täidetakse appleti initsialiseerimisel (s.t. enne ekraanile ilmumist). Programmi varasemates versioonides suhtlesin iga objektiga (nupuga, tekstiväljaga) eraldi, sest arvasin et nii on lihtsam ja lollikindlam kirjutada. Hiljem avastasin, et programmi saab muuta selgemaks ja kergemini muudetavaks, kui loon sarnastest objektidest massiivi. Nii saan luua objektide väärtustamiseks tsüklid. Protseduuris init paigutan komponendid ekraanile paneelide abil ning annan neile vajalikud algväärtused. Õpilaste ekraani puhul jagan suure ekraani kaheks BorderLayout abil. Alumisse "Lõuna" ossa jäävad tahvlid ning ülemisse "keskossa" tekstiaknad. Sellise jagamise puhul saan kergesti muuta Appleti suurust leheküljel. Alumine tahvliosa jääb ikka samasuureks (sest BorderLayout hoiab võimaluse korral servadesse pandud komponente nende soovitud suuruses), samas aga tekstipiirkond venitatakse välja ülejäänud ulatuses. Kasutajaaknad on laotud tabelina GridLayouti abil. Neis moodustab venitatava keskosa tekstipiirkond ning allserva märgend masina nimega. Õpetaja aknas on lisaks veel nupud kasutajale isikliku teate saatmiseks, tema vaatamisõiguse (kas näeb vaid iseennast ja õpetajat või ka teisi) muutmiseks ning mõne versiooni puhul ka kasutaja väljaviskamiseks. Protseduuri init lõpul olevad read  chatConnectionThread = new Thread(this); ning  chatConnectionThread.start(); käivitavad käivitavad uue lõime (Thread) suhtlemiseks serveriga. Siin programmis run kõigepealt loob ühenduse serveripoolse programmiga (Soketi abil), seejärel loob sisend- ning väljundvoo. Sisendvoolt ootab serveripoolseid teateid ning väljundvoo kaudu saadab omi andmeid sinna.
	Klass Thread või temaga sarnaseid funktsioone täitev mitmest pärimist lubav abstraktne klass (interface) Runnable võimaldavad üheaegselt programmil teostada mitut operatsiooni. Praeguses programmis saab näiteks jätta ühe lõime rahus serverist tulevat teadet ootama nii, et see muud programmi ei segaks. Ühelõimelistes programmeerimiskeeltes saab säärast ootamisprobleemi lahendada nii, et miski silmus pidevalt kontrollib, kas lõimele on tööd saabunud. Saabumise korral töödeldakse vastav teade ning siis jäädakse jälle teadet ootama. Käivitamisel (meetodi start väljakutsel) hakatakse käivitama selle klassi meetodit run, mis anti lõime konstruktorile initsialiseerimisel parameetriks. Näites new Thread(this) tähendab, et lõime käivitamisel hakatakse täitma appleti enda meetodit run. This tähendab objekti ennast (ehk enamasti objekti viita enesele). 
	Meetod action kutsutakse java 1.0 puhul appletis välja sündmuse  puhul (vajutus nupule jne.). Hilisemates java versioonides tuleb lisaks meetodi ülekirjutamisele end ka veel vajalike sündmuste kuulajaks (listener) registreerida. Ma ei teagi, kumb võimalus parem on. Ilma registreerimata on mugavam programme kirjutada, kuid tõenäoliselt tuleb tulemus ökonoomsem juhul, kui ilmaasjata kõiki mööduvaid sündmusi kinni ei püüta.  Meetodis action kirjeldan ükshaaval, mida mingi sündmuse puhul tuleb teha. Kui on vajutatud saatmise nupule, siis selle tulemusena tehakse sisestatava teksti kasti tekst objekti StringTokenizer abil ridade kaupa lõikudeks. Igale lõigule lisatakse päis: t näitab et tegemist tekstiga, muutujas ise hoitakse kasutaja enese numbrit, sk näitab kellele saata ning o on lihtsalt ruumitäiteks, et päis saaks nelja sümboli pikkune. Meetod write saadab lõigu väljundvoo kaudu serveri poole teele, siis kustutatakse sisendkastis olev tekst ning lõpetuseks kutsutakse välja sisendkasti meetod requestFocus, mis muudab kasti taas aktiivseks ning võimaldab sinna sisestada. Selle puudumisel kippus aktiivseks jääma nupp, millele vajutati teksti saatmiseks ning uueks kirjutamiseks tuli kast täiendavalt märgistada, mis aga kirjutamisehoos ununema kippus. Tekstisisetuskastile tuli juurde kirjutada protseduur, mis read sobivalt kauguselt poolitaks, et need lugejale ka ilma kerimata nähtavad oleksid. Kirjutamishoos lihtsalt kipub ununema, et rida kole pikaks läheb, kui vahepeal uuele reale üle ei lähe. Kirjutusmasinate ajastust on piisavalt aega möödas ning miks peakski arvutikasutaja reapikkuse-suguste probleemide üle oma pead vaevama. Et poolitamine sobiks kõikide kasutatavate keelte korral, selleks tõstan teksti järgmisse ritta alates reapikkust ületavast sõnast (ehk arvuti mõistes panen vastavale sõnale eelneva tühiku asemele reavahetussümboli).
	Õpetaja peab pidevalt jälgima, et ta kellegi küsimust või ütlust tähelepanuta ei jätaks. Selleks pakkus juhendaja välja  võimaluse, et osaleja, kellele pole veel vastatud, tekst peab olema kuidagi märgistatud. Loomulik tunduks see tekst eristada teise värviga, kuid java esimese versiooniga ei tahtnud kuidagi õnnestuda osa teksti ühe- ning osa teisevärvilisena näidata. Selle peale mõtlesin välja mooduse, mis töötab ka mustvalge ekraani peal: vastamata ridade ette lisasin kaks hüüumärki. Kui õpetaja kasutajale vastab, siis kaovad hüüumärgid ridade eest ära. Programmiliselt lisasin TextArea alamklassile Ta1 kaks meetodit: juurde(String s) kirjutab tekstikasti ekraanile juurde hüüumärkidega algava lisatud rea. Hüüumärkideta rida lisatakse muutujale lisa. Meetod korras() asendab eelmise vastamiseni olnud tekstist kuni lõpuni oleva hüüumärkidega algava osa asemele muutuja lisa sisu ning jätab meelde, et sinnamaani on vastatud tekst. 
	
	Kasutamise käigus tehtud parandused ning edaspidised võimalused jututoa kasutamise parandamiseks.

	Novembris 1998 toimunud internetipõhisel modelleerimiskursusel kasutati eelkirjeldatud sidepidamisvahendit. Ilmnes mitmeid probleeme ning koos sellega ka parandamisvõimalusi. 
	Kuigi olin püüdnud teha kasutamise võimalikult lihtsaks, jäi esimesel korral ühendus Tehnikaülikooliga pidamata, sest kardeti, et pole tehnikut käepärast ning ei juletud ühendust proovidagi. Võibolla peaks temaga koos käima julgustav-tutvustav tekst ehk kasutusjuhend. Kuigi kasutamine ei tohiks olla oluliselt keerulisem ajalehe lugemisest võib tundmatu nimetus jututuba kasutajatele esmapilgul tekitada võõristust. Aitaksid ka selgitavad tekstid/pildid töötava jututoalehekülje komponentide juures, kuid samas muudaksid nad hilisemal kasutamisel jälle pildi segasemaks ning kohmakamaks. Samuti muutuks siis programm sõltuvaks kasutajate keeleoskusest, sest sakslased ei pruugi mitte eestikeelsetest seletustest aru saada ning ka vastupidi. Piltkirjas sümbolidon küll kasutades head ja ülevaatlikud, kuid esmakordsel kasutamisel võivad tekitada raskusi. Pole ju kuigi kerge välja mõelda, et lainetus nupu peal tähistab lainelise joone tõmbamise võimalust ja mitte midagi muud (näiteks kogu pildi väljanägemise muutmist lainetuse sarnaseks). See aga pole mitte sellele jututoale spetsiifiline vaid on pea kõikide arvutiprogrammide probleem.
	Võimalus, et programm lehekülje avamisel kohe serveriga ühendust võtab, on kasutajale mugav, kuna ta ei pea ühenduse loomiseks enam midagi täiendavalt ette võtma. See tekitab aga ohu, et lehekülje taaslaadimisel (kas siis ettekavatsematult lehekülje suuruse muutmise teel, vahepeal teisi lehekülgi vaadates või mõnel muul moel) asub applet taas serveriga ühendust võtma. Kui ta aga ei taipa vana ühendust ära katkestada, siis tekib kasutajal juba kaks ühendust serveriga. Kuna see programm aga arvestab kasutamisel vaid nelja õpilaskohaga, siis tuleb see teine "zombie" kanal kellegi arvelt. Selle vältimiseks lõin programmi vahendi, mis lubab ühest masinast korraga vaid ühel kanalil asuda.  Kui võetakse uus ühendus samast masinast, siis eelmine katkestatakse. Tegemist ei ole tõenäoliselt mitte selle probleemi parima lahendusega, kuid ta vähemalt võimaldas automaatselt hoolitseda, et keegi liialt kanaleid ei raiskaks. 
	Kasutaja identifitseerimiseks kasutan tema masina aadressi. Selline tehniline komponent ei tule küll enamasti programmi inimlikule küljele kasuks, kuid ta võimaldab kergesti määrata kasutaja asukoha (juhul kui viimane selle varjamiseks erilist vaeva ei näe). Kasutajanimi ja parool oleksid viisakamateks võimalusteks, kuid siis lisandub kasutajale nende sisestamise ning meelespidamise kohustus. 
	Logifailide abil saab ilusti tagantjärele vaadata, kuidas programm töötanud ning mida keegi kirjutanud ja saatnud on. Sealsest infohulgast võib kasutajal enamasti ainult suhteliselt väikest osa vaja minna ning kogu sellest kirjust rägastikust üles otsida võib teda tüütu olla. Selleks lõin abi(cgi)programmi, mis kasutajale ekraanile toob vaid kasutajate poolt saadetud tekstid. Paremal juhul aga peaks logifailidest lugemiseks olema säärane programm, mis väljastab andmeid vastavalt päringule. Enamvajalikud päringud (näiteks kahe kasutaja vahel suheldud tekst) võiksid olla valitavad, ülejäänud päringuid peaks saama ise koostada. Nii saab vaadata eelmiseid tunde ning nende headest ja halbadest külgedest õppida. Kui praegu salvestan ja edastan pilte stringidena, siis saan neid vaadata vaid appleti abil. Soovides aga kasutajate vahel saadetud valemihulki vaadata tuleb igaühe jaoks eraldi applet käivitada. See nõuab päris palju mälu ning ka paremate masinate korral pole mul õnnestunud üle paarikümne pildi vaadata. Selleks puhuks võiks aidata vaatefailis näiteks gif'idena esitatud pildid.
	Võrgu aegluse tõttu ei saa alati kindlalt väita, kas serveri ja kasutaja vahel on ühendus olemas või mitte. Kui ühendus on katkenud, siis on serveri pool kasulik selle ühenduse poolne ruum vabastada. Nii teevadki mitmed jututoad, kus ühenduse probleemide korral ühendus koheselt katkestatakse. Tulemuseks on aga et halva side korral ei saagi rahulikult kirjutada, pead end pidevalt uuesti ühendama. Ja kui selleks ühenduseks tuleb veel brauser taaskäivitada, siis raisatakse selle peale küllalt palju energiat. Kui ühenduse kadumist mitte arvestada, siis võib aga juhtuda, et serverisse jäävad päevadeks rippuma "surnud" kasutajad. Vahepealseks variandiks peaks olema, et kasutaja võetakse serveripoolse programmi nimekirjast maha mingi aja (näiteks viie minuti) pärast  pärast ühenduse kadumist. See muudab muidugi serveripoolse programmi veidi keerukamaks. Võimalik oleks luua ka süsteem, kus applet samuti kontrollib ühenduse olemasolu ning selle katkemisel üritab uuesti ühendust võtta, ühendamisel teatades, et tegemist on uue ühendusega sama kasutaja ja sama masina juurest. Katsetel selgus, et ühendus võib ka ühepoolselt kaduda. Ka selleks puhuks tuleks midagi välja mõelda. Ning ehk tuleks ühendust kontrollida mõlemalt poolt.
	Tulenevalt jututoa loomusest ei saa ka kasutajate vahelisest sidemest muud moodi sotti, kui saadetud tekstide ja piltide järgi. Katsel selgus, et õpetaja ei saa sageli mitte aru, kas teiselt poolt paistev vaikus on tingitud sealsest agarast mõttetööst või pole nad eelnevast aru saanud ning istuvad niisama. Et õpetajal oleks kergem kasvõi vaikimise aegagi kontrollida, selleks võiks iga kasutaja juures olla kell, mis näitaks minuteid tema viimasest sõnumist.
	Suurema kasutatavuse korral kuluks eraldi valmistada administraatori lehekülg koos sinna juurde kuuluva appletiga. Ise kui programmeerija saan tekkinud viperusi parandada tekstiterminali kaudu süsteemile käske saates ning serveri faile kopeerides-kustutades, kuid neid nippe üles kirjutada on tüütu- ja tülikavõitu ning kirjeldust lugeda arvuti tavakasutajast pedagoogil keeruline ja aeganõudev. Mõnel juhul võib kirjelduse loomine-kasutamine enam aega võtta kui programmi valmistamine. 
	Administraator peaks rakendusprogrammi abil saama kinni jäänud kasutaja ühendust katkestada. (Hättasattunu ühendamine kuluks muidugi ka ära, kuid sellise jupi kirjutamine kasutaja masinale liiga tegemata osutuks vist keeruliseks :-). ) Peaks saama logifaile kopeerida ning nende asukohta muuta, sest muidu suure kasutamise korral muutuvad need kergesti kole suurteks (enamjaolt piltide tõttu) ning raskesti loetavateks. Peaks saama saata kasutajatele teateid ning ka serveripoolset programmi vajadusel seisata ning taaskäivitada.