[FOTOBOEK] Koentjuh ??
 

eeh .. miss gewaagt maar is het niet een goed idee om echt JAVA te gebruiken ipv php en javascript..

ow en ik heb nog zo'n mooi dik toverboek

Thinking in JAVA van Bruce Eckel ;)

heb het idee dat dat ook ietsje sneller gaat want dan kan de CODE lokaal draaien

Dat wil je toch niet? Bovendien wat is het voordeel? De images en data moet nog steeds van s.com server komen hoor. En niet iedereen heeft java geinstalleerd, waaronder ik. Trage crapzooi, vooral bij het opstarten.

Zie het voordeel niet. Bovendien denk je dat hij het hele fotoboek gaat herschrijven?

Nou Zweepje heeft een boek, dus laten we het hem doen...
Zweepje maak even eene testversie (natuurlijk wel die werk met je test-server en niet die van scholieren) die er ongeveer uit ziet als het huidige fotoboek..
als je 't afhebt post een link en wie weet :)

heu dat hoeft ie dan echt niet alleen te doen ;)

voordeel .. hmmja miss dat ie dan wat sneller laad en stabieler is
normaal ben ik geen voorstander van java hoor ( C++ RULES :D )

Ja en wie weet spoel ik dan honderden uren werk door de plee om maar eens een Java versie te bouwen zeker. Dacht 't ook.

Daarnaast ben ik 't met Enlightenment eens, ik zie geen voordelen. Community sites als het fotoboek zijn ideale projecten om júist met PHP/MySQL te doen.

if you say so :D

noujaah ik heb ook wel es een programma ik 3 verschillende talen gebouwt gewoon om te kijken wat het beste werkt ;)

was ook maar 'n idee .. het laden duurt nl soms ERRUG lang.

ik heb trouwens gemerkt dat als je niet ingelogd bent en je klikt op info & foto's dan krijg je weer de zelfde pagina ..

Als 't werkt als het huidige kan je zo een groot aantal uren schrappen...
en dan kan de java versie gewoon als desktop programma gebruikt worden, naast 't php ding :p

is miss wat voor te zeggen om de foto's dan eerst te comprimeren dan te versturen en dan weer te inflaten .. dan zou het laden toch sneller moeten gaan ?

moet nog ergens een stuk LWZ achtige compressie code hebben .. is wel C++ :)

Goed.. even de mening van een leek. Het klinkt als een heleboel werk en wat mij betreft is het fotoboek (en zijn snelheid) prima zo.

:confused:

:)

De snelheid zal idd voornamelijk liggen aan de verbinding van de bezoeker en de drukte op het moment van het bezoek...
De snelheden zouden pas uitmaken bij veel meer gebruikers (en dan ook tegelijke tijd) volgens mij

Ja, en je moet je dan afvragen of het de moeite waard is. Zoals ik al zei: ik ben een leek. Ik heb geen flauw idee hoeveel moeite het is en ik heb geen flauw idee hoeveel dit uitmaakt in snelheden. Maar ik heb het idee dat de snelheid van het fotoboek voor de meesten prima is zo. En dan kan je *bla* uren tijd steken in het sneller maken van iets wat op zich al goed werkt. Of je kan diezelfde uren steken in iets nuttigers.

Denk ik.

Mja m'n eerste post was een beetje sarcastisch... imo is het niet de moeite waard... ik zie net in de statestieken dat er 505 bezoekers per uur waren op een gegeven moment... Koen weet de exacte nummers... en ook hoeveel serverload het met zich meeneemt... zolang deze binnen een gestelde grens is (en daar heeft Koen vast ook over nagedacht) is er geen probleem...
Daarnaast zal er geen geld/levens verloren als 't fotoboek niet snel/goed werkt... dus zullen de kleine snelheid verhogingen er niet toe doen...
bij transacties op een database met duizenden klanten en honderden gebruikers zijn het zeker afwegingen om te maken... (maar goed, die zullen niet zo omslachtig werken) want tijd is geld en geld moet rollen (ofzo) :>

't werk voor bijv. het fotoboek is zover ik weet vrijwillig en onbetaald dus als iemand er tijd in wil steken... waarom niet...
maar de vraag is eerder is 't nuttig voor de site, wat voegt 't toe, wat wordt er beter van?

JPEG laat zien vrijwel niet meer comprimeren, zelfs 7zip, verreweg de beste compressiemethode, weet er nauwelijks iets af te snoepen. GIF is gebaseerd op LZW-compressie, ik denk dat je dit bedoelt. JPEG is weer op een andere/eigen compressiemethode gebaseerd, waar ik te weinig vanaf weet. Maar mijn dir met g**l* foto's RARen heeft bijvoorbeeld weinig zin. :p

Nee. LZW heeft ook erg veel nut op plaatjes met JPG compressie :rolleyes:

Weet jij absoluut zeker dat jij iets informatica-achtigs gestudeerd hebt?

Je was me iets te snel af, maargoed. JPEG is lossy, GIF (LZW) niet. JPEG valt simpelweg niet verder te comprimeren daar het min of meer 'random' data is.

Wat betreft dat Java verhaal: complete onzin. Je creeert een hoop problemen (niet iedereen heeft een (up-to-date) Java-VM), terwijl het geen oplossing biedt voor hetr 'probleem' (lage transferrate vanaf de s.com server).

eeh ja maar C++ AI, en OpenGL zijn mijn specialiteiten ..
servers en databases niet zo .. was ook maar 'n wild ideee

Wat een bullshit, JAVA is echt een klotetaal om dit in te schrijven. Het mag duidelijk zijn dat PHP/MySQL de toekomst is voor server/client toepassingen zoals dit fotoboek.

hmm ja kijk voor stand alone applicaties en spellen is het nl helemaal om te huilen .. maar mij hebben ze dus wijs gemaakt dat als je snelle dingen op internet wil .. nu ja het zal wel ..
maar als 't hier voor ook niet werkt .....

wat moet je DAN met java ???

ook goed ik ga een RTS bouwen in C++ wie doet er mee :D

Heheheh.

Het spijt me, maar de meeste ECHTE wepabbplicaties zijn toch echt JSP/Oracle of ASP/SQLServer systemen. Er zijn bijzonder weinig grote bedrijven die hun spul in PHP afleveren.

JSP for teh win.

maar die doen HET dus ook niet met java ?

En die code moet je ook downloaden, en is meer dan gewoon html en javascript..

Dit is wel echt het slechtse idee wat ik tot nu toe heb gehoord :X

JSP = Java Server Pages.

Applets worden net zo goed gecached, dus dat is geen argument.

Ik heb het dan ook niet over bedrijven maar over kleinschalige projecten zoals het fotoboek ;)

Vrijwel alle fora zijn geschreven in PHP, althans die ik ken. PHP/MySQL is een zeer populaire combinatie voor webbased dynamische omgevingen. Grote bedrijven vind ik niet zo interessant. Scholieren.com is ook geen groot bedrijf. Dat betekent niet dat PHP niet ook populair zou zijn in de toekomst, niet alleen de 'grote bedrijven' bepalen die met hun bloated proprietary apps.

...en da's een meisje :confused:

heej post eens een foto :D

Ik wel, en ik had het statement van Vaal verkeerd begrepen. En dat de meeste fora op PHP en MySQL draaien: beetje duh verhaal he?

:rolleyes:

*PROEST*

... ook lid van de rolleye fanclub ? :p :D

Dat niet zozeer, maar bij sommige leden is het nou eenmaal de enige reactie die je kunt geven.

Wat heb jij toch met het woord "bloated"?

Dat snap ik,
maar een zelfde soort pagina laden in java duurt langer dan zo'n agina in html/css volgens mij.