[AJAX] Chat applicatie, advies gevraagd

[chuxiej]

Beste Tweakers,

Voor een toekomstig project hebben wij een chat applicatie nodig.
Nu twijfelen wij heel erg aan de mogelijkheden die er zijn om dit waar te maken.
Wij hebben 2 mogelijkheden en zouden advies van personen met ervaring hiermee erg op prijs stellen.
Onze voorkeur gaat echt uit naar de PHP/Javascript manier aangezien wij deze zelf kunnen programmeren en uitbreiden.

De vragen zijn:
1. Kan een PHP/Javascript based client een hoog bezoekers aantal (meer dan 1000 chatters op het zelfde moment) aan zonder delay/lag?
2. Zitten er grote nadelen aan het maken van de client in PHP/Javascript?
3. Kan iemand een hele ruwe indicatie geven hoeveel wij kwijt zullen zijn voor een chatbox met de onderstaande functionaliteiten?
4. Kan iemand een hele ruwe indicatie geven hoeveel wij kwijt zullen zijn voor java webcam applicatie?

Functionaliteiten chatbox:
- Meerdere kanalen
- Prive chats
- Webcam mogelijkheden in prive chats (java)
- Profiel kunnen bekijken

Server:
PHP-CGI programma welke op de server blijft draaien

Client:
- PHP / Javascript based, in een iframe blijft een php script zonder execution_time/timelimit draaien welke javascript commando's verstuurd naar main chatwindow
- Java based client


PHP client
Voordelen
- Makkelijk zelf aan te passen en nieuwe functies toe te voegen
- Lagere productie kosten


Java client
Voordelen
- Meer real time

Nadelen
- Moeilijk dingen zelf aan te passen
- Hoge productie kosten

Bedankt voor de hulp!

[RobIII]

Waarom, als ik een domme vraag mag stellen, gebruik je niet 1 van de vele, vele oplossingen die er al zijn (al dan niet gratis)? Waarom het wiel opnieuw uitvinden, zeker als je in je schoenen staat zoals jij nu overkomt. Dit bedoel ik niet verkeerd, maar ik heb het idee dat jullie nog niet echt "overtuigd" zijn van jullie eigen kunnen. Er zijn zat prima applicaties voor chat/cam om te integreren in je eigen site (ik neem aan dat het daarom gaat, since je php/javascript laat vallen).

[ Voor 20% gewijzigd door RobIII op 04-05-2006 23:45 ]

[chuxiej]

Omdat het voor commerciele doeleinden is en nog een aantal redenen.

[NMe]

chuxiej schreef op donderdag 04 mei 2006 @ 23:40:
1. Kan een PHP/Javascript based client een hoog bezoekers aantal (meer dan 1000 chatters op het zelfde moment) aan zonder delay/lag?

Dat hangt maar net van de server af waar het op draait. PHP is de beperkende factor niet, en Javascript al helemaal niet, aangezien Javascripts bij de client draaien.

2. Zitten er grote nadelen aan het maken van de client in PHP/Javascript?

Je bent nooit 100% realtime bezig en zal veel requests doen naar je server om toch die indruk te kunnen wekken. Wat dat betreft zal het zaakje aardig vertraagd worden door een AJAX-oplossing.

3. Kan iemand een hele ruwe indicatie geven hoeveel wij kwijt zullen zijn voor een chatbox met de onderstaande functionaliteiten?
4. Kan iemand een hele ruwe indicatie geven hoeveel wij kwijt zullen zijn voor java webcam applicatie?

Hoeveel jullie kwijt zijn? In geld? Kun je dat niet beter vragen aan degene die het voor je gaat schrijven als je dat zelf niet wil doen? Wij kunnen je daar geen indicatie van geven omdat een prijs direct afhankelijk is van het uurloon van de programmeur, de snelheid waarop hij werkt en de eisen die je stelt aan de applicatie, inclusief de snelheid waarmee je de applicatie nodig hebt.

[RobIII]

chuxiej schreef op donderdag 04 mei 2006 @ 23:47:
Omdat het voor commerciele doeleinden is en nog een aantal redenen.

Er zijn ook zat projecten die je "gewoon" commercieel in mag zetten (mits je dus gewoon de juiste licentie o.i.d. afneemt).
En anders: Kijk eens naar een java applet dat je kunt verbinden met een IRC server. In dat geval hoef je alleen nog maar een IRC server op te zetten om je chat-goedoe aan de praat te krijgen (zie bijvoorbeeld irc.tweakers.net).
Voor de cam zijn er, zoals ik al aangaf, ook voldoende applets die je daarvoor (al dan niet commercieel) kunt gebruiken. Ook flash kan dit tegenwoordig.

-NMe- schreef op donderdag 04 mei 2006 @ 23:49:
Hoeveel jullie kwijt zijn? In geld? Kun je dat niet beter vragen aan degene die het voor je gaat schrijven als je dat zelf niet wil doen? Wij kunnen je daar geen indicatie van geven omdat een prijs direct afhankelijk is van het uurloon van de programmeur, de snelheid waarop hij werkt en de eisen die je stelt aan de applicatie, inclusief de snelheid waarmee je de applicatie nodig hebt.

^^ Met hem

offtopic:
-NMe-

[ Voor 30% gewijzigd door RobIII op 04-05-2006 23:51 ]

[chuxiej]

We willen het niet via AJAX doen aangezien dit door het pollen van de server erg veel load zal kosten.
Wij hadden echt in gedachten een php script constant in een hidden iframe te laten draaien welke javascript functies aanroept.

[NMe]

Wat denk je dat AJAX doet? Lees die link eens door.

[RobIII]

chuxiej schreef op vrijdag 05 mei 2006 @ 00:04:
We willen het niet via AJAX doen aangezien dit door het pollen van de server erg veel load zal kosten.
Wij hadden echt in gedachten een php script constant in een hidden iframe te laten draaien welke javascript functies aanroept.

En exactly hoe maakt dat de load lichter
Met alle respect, ik bedoel het goed, maar ik denk dat je "way over your head" zit. Zeker als je met meer dan 1000 chatters (zoals je aangeeft in je TS) aan de slag wil is dit soort "plakbandoplossingen" niet echt wat je wil (of zou moeten willen).

Los daarvan wil je eigenlijk een "push" mechanisme, en AJAX, I-frame of whatever: dat gaat je zo niet lukken. Je zult echt een applet of iets dergelijks moeten laden dat zelf een ontvangend kanaal kan openzetten.

[ Voor 20% gewijzigd door RobIII op 05-05-2006 00:09 ]

[kmf]

chuxiej schreef op vrijdag 05 mei 2006 @ 00:04:
We willen het niet via AJAX doen aangezien dit door het pollen van de server erg veel load zal kosten.
Wij hadden echt in gedachten een php script constant in een hidden iframe te laten draaien welke javascript functies aanroept.

een phpscript in een iframe die javascript aanroept?

[CyBeR]

Ik zou 's kijken naar Comet. http://alex.dojotoolkit.org/?p=545.

[Soultaker]

chuxiej schreef op donderdag 04 mei 2006 @ 23:40:
De vragen zijn:
1. Kan een PHP/Javascript based client een hoog bezoekers aantal (meer dan 1000 chatters op het zelfde moment) aan zonder delay/lag?

Nee. Je webserver kan out-of-the-box zeker geen 1000 concurrente verbindingen aan. Als je 1000 PHP-threads gaat draaien rijst het geheugengebruik sowieso de pan uit. Pollen (met honderden requests per seconde) is helemaal geen optie.

2. Zitten er grote nadelen aan het maken van de client in PHP/Javascript?

Ja, HTTP is een stateless protocol en hiervoor dus ongeschikt. Je kunt wel wat trucs verzinnen maar die zijn onbetrouwbaar, traag en/of niet-portable.

Sowieso ga je aan het grootste probleem voorbij en dat is dat het moeilijk is om server-side al die connecties aan elkaar te koppelen, ook weer omdat HTTP daar niet voor ontworpen is. Met CGI is daar in theorie wel omheen te werken, maar hoe je het met PHP wil doen is me nog onduidelijk (heb je daar ueberhaupt over nagedacht?).

Als je toch met Java aan de slag gaat (voor je webcam) schrijf dan je hele chatbox daarin. Naar mijn idee is dat de enige aanpak die enigzins schaalbaar is. 'Grote' websites zoals Spelpunt.nl of Yahoo's chatboxen gebruiken niet voor niets Java. Het betekent ook echter dat je waarschijnlijk een server moet schrijven (in plaats van HTTP te gebruiken); dat kan ik PHP maar waarschijnlijk is Java een veel betere keuze.

[Deniax]

Soultaker schreef op vrijdag 05 mei 2006 @ 00:41:[...]'Grote' websites zoals Spelpunt.nl of Yahoo's chatboxen gebruiken niet voor niets Java.

De gameapplet van Spelpunt gebruikt idd Java, maar de (chat)techniek eronder is gewoon plain old IRC

[Sv3n]

Ik heb vorig semester (afgelopen najaar) eeen webbased chatapplicatie moeten schrijven, alleen niet met php maar met servlets en jsp's, het kan, het is makkelijk te doen, maar het is zo ongelovelijk ranzig om over een http connectie te gaan chatten(je gebruikt het protocol voor dingen waar het niet voor bedoeld is). Als je het dan toch op je website wil, maak een java applet, irc of eigen protocol, maakt niet zoveel uit, dat is een zoveel mooiere oplossing dan met php/asp/jsp en hoeft echt niet veel extra werk te zijn. Als je een protocol hebt dat berichten naar de gebruikers stuurt ipv. dat de gebruikers elke keer vraagt om nieuwe berichten(vaak nutteloos, hij weet immers niet of er wat is), scheelt dat heel veel aan load

Owja, java en bewegende beelden, het kan, maar ook niet echt aan te raden Ik heb (ook vorig semester) een applicatie gemaakt die dmv. een java applet op een website een stream oppikte van een webcam, jah het werkt, maar niet echt de ideale manier, moeten de mense die er gebruik van maken sowieso het (naar mijn mening niet goed doorontwikkelde) java media framework installeren. Daarnaast kost het redelijk wat bandbreedte en load.

[ Voor 11% gewijzigd door Sv3n op 17-05-2006 23:20 ]

[Erkens]

Soultaker schreef op vrijdag 05 mei 2006 @ 00:41:
Sowieso ga je aan het grootste probleem voorbij en dat is dat het moeilijk is om server-side al die connecties aan elkaar te koppelen, ook weer omdat HTTP daar niet voor ontworpen is. Met CGI is daar in theorie wel omheen te werken, maar hoe je het met PHP wil doen is me nog onduidelijk (heb je daar ueberhaupt over nagedacht?).

Waarom zou het met CGI in theorie wel kunnen en met PHP niet? de technieken zijn immers hetzelfde

---

Ik heb lang geleden ook een chat applicatie moeten schrijven met PHP, via HTTP verbindingen die je open laat staan dan wel (hidden iframe waar data, javascript, blijft binnen stromen). Enkel door het gebruik van een lichte server (weet even niet meer wat we hadden gebruikt) was het goed te doen voor circa 150man, daarna hield het al vrij snel op. Meer hadden we toch niet nodig.

[CaptBiele]

chatroompje met ajax

het is in ASP.NET 2.0, dus het heeft misschien niet jouw voorkeur.
wellicht kan je het gebruiken voor wat orientatie, want qua performance maakt het geen zak uit.
Ajax gebruikt gewoon javascript op de achtergrond.

[JHS]

Het kan best: http://www.campfirenow.com/ . En ik vind het eerlijkgezegd best goed werken.

edit:

Maar dat is niet in PHP natuurlijk .

[ Voor 23% gewijzigd door JHS op 18-05-2006 09:50 ]

[Janoz]

Waarom zou het met CGI in theorie wel kunnen en met PHP niet? de technieken zijn immers hetzelfde

Php is als het ware een subset van CGI. CGI is enkel 'hoe de server een externe applicatie aanroept' terwijl php een complete scripttaal is. Omdat CGI minder beperkingen oplegt is er met CGI in principe meer mogelijk.

Het grote probleem waar je tegenaan gaat lopen met php (en dat is ook waar Soultaker het over heeft) is dat php helemaal geen application scope heeft.

[Erkens]

Janoz schreef op donderdag 18 mei 2006 @ 09:48:
Php is als het ware een subset van CGI. CGI is enkel 'hoe de server een externe applicatie aanroept' terwijl php een complete scripttaal is. Omdat CGI minder beperkingen oplegt is er met CGI in principe meer mogelijk.

Niet helemaal waar, aangezien PHP precies dezelfde mogelijkheden heeft als elke random scripttaal die je zou kunnen gebruiken met CGI

Het grote probleem waar je tegenaan gaat lopen met php (en dat is ook waar Soultaker het over heeft) is dat php helemaal geen application scope heeft.

niet standaard nee, maar dat wil niet zeggen dat het niet eenvoudig te doen is

[sariel]

Imho, zul je al heel snel aan 2 opties zitten:
- Een java client
- Een flash client

De java client is wat lastiger om in elkaar te zetten, maar kan je gewoon laten werken met een default IRC server. Webcam er bij zal dan nog een aardige klus zijn.

De flash client is SCHREEUWEND DUUR, mede omdat je een flash communications server nodig hebt. Een irc server voor flash zeg maar. Het voordeel is dat je dan meteen ook een webcam en overige shit in kan bouwen, relatief simpel.

[sariel]

Zie http://www.adobe.com/products/flashmediaserver/ voor de flash server.

edit: voorbeeld van zo'n applicatie: http://www.123flashchat.com/demo.html

[ Voor 35% gewijzigd door sariel op 18-05-2006 10:44 ]

[Janoz]

Dat is niet helemaal waar. CGI is gewoon een manier van de webbrowser om een willekeurige executable aan te roepen en daarbij de parameters door te geven. Of dit wordt doorgegeven aan een batch script of een mbv assembly gemaakte executable maakt niet uit. Ik neem aan dat zelfs jij niet kunt ontkennen dat je met C meer kunt dan met php.

Het enige dat nog en beetje in de buurt komt van een application scope is het non standaard en lang niet overal werkend shared memory van php. Om nu te zeggen dat het goed gebruiken hiervan voor een chat applicatie 'eenvoudig' is vind ik persoonlijk nogal erg kort door de bocht.

[Erkens]

Janoz schreef op donderdag 18 mei 2006 @ 10:25:
Dat is niet helemaal waar. CGI is gewoon een manier van de webbrowser om een willekeurige executable aan te roepen en daarbij de parameters door te geven. Of dit wordt doorgegeven aan een batch script of een mbv assembly gemaakte executable maakt niet uit. Ik neem aan dat zelfs jij niet kunt ontkennen dat je met C meer kunt dan met php.

O, dat ontken ik ook niet, maar er is maar weinig wat niet met PHP kan, en ik kan je wel vertellen dat je voor een simpele chat applicatie geen application-scope nodig hebt. Welke je trouwens ook niet hebt met standaard C(GI)

[SilentSimon]

Is zoiets niet te doen met RIA?
Een applicatie in Flash wat een directe verbinding met de DB heeft.
Ikzelf werk al 2 jaar met RIA's en ik denk dat het best kan werken.
op dit moment gebruiken wij openAMF in samenwerking met het AriaWare platform om realtime verbinding te maken met de database. Werkt erg goed.

[ Voor 20% gewijzigd door SilentSimon op 18-05-2006 10:44 ]

[JHS]

SilentSimon: Een Rich Internet Application lijkt mij veeleerder het type applicatie, dan de gebruikte methode. Er worden dan wel een aantal methodes onder geschaard, maar dat maakt lijkt mij niet duidelijk wélke methodes in dit geval de juiste / beste zijn. En dat was dacht ik de vraag ?

[sariel]

AMF-PHP ziet er inderdaad wel geinig uit....misschien zou je daar inderdaad naar kunnen kijken, kende ik nog niet (php versie van openamf, of eigenlijk andersom)

[sariel]

JHS schreef op donderdag 18 mei 2006 @ 10:46:
SilentSimon: Een Rich Internet Application lijkt mij veeleerder het type applicatie, dan de gebruikte methode. Er worden dan wel een aantal methodes onder geschaard, maar dat maakt lijkt mij niet duidelijk wélke methodes in dit geval de juiste / beste zijn. En dat was dacht ik de vraag ?

Ja, maar wij kunnen niet bepalen wat voor hem de beste optie is, tenzij het over-overduidelijk is (keuze tussen 2 hele slechten en 1 goede bijvoorbeeld).

In dit geval hangt het er van af wat hij het makkelijkste vind, en het beste vind werken. Daarom is het (nmm) beter om een lijstje opties te hebben, die hij dan zelf af kan werken, en kan kiezen welke genomen wordt.

[Janoz]

Erkens schreef op donderdag 18 mei 2006 @ 10:33:
[...]

O, dat ontken ik ook niet, maar er is maar weinig wat niet met PHP kan, en ik kan je wel vertellen dat je voor een simpele chat applicatie geen application-scope nodig hebt.

Vertel maar dan.

Welke je trouwens ook niet hebt met standaard C(GI)

In C heb je keurig mogelijkheden om gedeelt geheugen fatseonlijk te implementeren. Je zou een master applicatie kunnen schrijven waarop (middels cgi opgestarte clients) aan kunnen sluiten. Deze master applicatie verdeeld vervolgens de verschillende onderlinge berichten tussen de verschillende clients.

[Verwijderd]

mijn tip php er af gooien!
Je hebt php niet nodig je kan alles schrijven in java. (niet javascript)
Dus is php overtollig.
Je onwikkeld wel sneller in php maar dat doet er niet toe als je en goed applicatie wil hebben de meeste tijd ben je niet bezig met code kloppen maar met vergaderen en uitzoeken.

Als je een goed java programeur kan vinden dan schrijft hij dit in een hand omdraai en kan je het later uitbreiden en veranderen naar gelieven.
Bij php in combinatie met javascript zal dat moeilijker worden, dus als dit een echte bedrijfs applicatie moet worden schrijf dan alles in java dat is mijn tip!
(php vindt ik persoonlijk een wat rommelige taal en niet goed geschikt voor grootte en belangrijke applicaties voor bedrijven) Voor een goed programmeur maakt het niet uit waar in hij programmeerd en dan kan je beter kiezen voor java als voor php.

Het probleem zal waarschijnlijk zijn om een goed programmeur te vinden die dit voor jullie wil doen.
Ik zou ook een database aan die chat functie koppelen.

Ik denk dat 1000+ chatters geen probleem moet zijn voor java alleen een probleem voor je server.
Ik zou gewoon een browser applicatie maken, dus een web pagina. (struts) geen "applet"

De kosten hangen geheel af van hoe goed de programeur/s zijn.
De meeste dingen die je nodig heb om dit te maken zijn al geschreven en kan je gewoon gebruiken als je ze aanpast gewoon zoeken naar java libs en deze ombouwen voor eigen gebruik.
Zet alles op met EJB's en koppel er een database aan voor de data en als front gebruik je struts.
Dus geen "applet" maken voor client.

Ik denk dat je in 3maanden met twee goed programmeurs gemakkelijk een shell moet kunnen bouwen. Je zal dan een test opstellinge hebben en deze verder ontwikkelen en fine tuning dat zou dan nog een paar maanden kunnen duren, afhankelijk van de eisen die de opdrachtgever. Dus 6maanden ? ofzo.
Kosten; wat betaal je die twee programeurs, wat heb je er voor over...
Probleem zal zijn om twee goed java programmeurs te vinden.

Als je in 'huis' twee goed programeur hebt kost het je dus niets.

Ik denk dat ik zo iets alleen zou kunnen maken in 4 a 6 maanden full time werken.
Je moet natuurlijk ook beveiligingen in bouwen en ander bijkomstige dingen, daar hou ik dus ook rekening mee met mijn schatting een ook met de installatie/aanschaf van de server.

boven staande is 'maar' mijn mening

[Erkens]

Janoz schreef op donderdag 18 mei 2006 @ 10:51:
Vertel maar dan.

best:

Je zou een master applicatie kunnen schrijven waarop (middels cgi opgestarte clients) aan kunnen sluiten. Deze master applicatie verdeeld vervolgens de verschillende onderlinge berichten tussen de verschillende clients.

^^ dat dus in PHP

[sariel]

Verwijderd schreef op donderdag 18 mei 2006 @ 10:52:
mijn tip php er af gooien!
Je hebt php niet nodig je kan alles schrijven in java. (niet javascript)
Dus is php overtollig.
Je onwikkeld wel sneller in php maar dat doet er niet toe als je en goed applicatie wil hebben de meeste tijd ben je niet bezig met code kloppen maar met vergaderen en uitzoeken.

Als je een goed java programeur kan vinden dan schrijft hij dit in een hand omdraai en kan je het later uitbreiden en veranderen naar gelieven.

Ja, dat klopt, maar daar had hij geen zin in, want ik maak op uit z'n post dat hij geen in-house java programmeurs heeft.

Bij php in combinatie met javascript zal dat moeilijker worden, dus als dit een echte bedrijfs applicatie moet worden schrijf dan alles in java dat is mijn tip!

Met PHP/javascript zal het inderdaad lastiger worden, alleen dat verhaal over dat bedrijfsapplicaties in Java moeten is grote bullshit. Ik heb genoeg BRAKKE shit gezien in java om te weten dat het niet uit maakt welke taal je schrijft, om troep te maken.

(php vindt ik persoonlijk een wat rommelige taal en niet goed geschikt voor grootte en belangrijke applicaties voor bedrijven) Voor een goed programmeur maakt het niet uit waar in hij programmeerd en dan kan je beter kiezen voor java als voor php.

Onzin. Je programmeert zoals je bent. Ben je een slechte programmeur, dan programmeer je slecht. Ben je een goede programmeur, dan programmeer je netjes. Het is bullshit om te zeggen dat PHP slecht is voor bedrijfs applicaties, en Java goed.

Het probleem zal waarschijnlijk zijn om een goed programmeur te vinden die dit voor jullie wil doen.
Ik zou ook een database aan die chat functie koppelen.

Ik denk dat 1000+ chatters geen probleem moet zijn voor java alleen een probleem voor je server.
Ik zou gewoon een browser applicatie maken, dus een web pagina. (struts) geen "applet"

En wat is er mis met een applet? Het zou prima kunnen werken in een applet, lijkt me. Het nadeel van een browser applicatie zou zijn dat het niet real-time is, en in een applet wel.

De kosten hangen geheel af van hoe goed de programeur/s zijn.
De meeste dingen die je nodig heb om dit te maken zijn al geschreven en kan je gewoon gebruiken als je ze aanpast gewoon zoeken naar java libs en deze ombouwen voor eigen gebruik.
Zet alles op met EJB's en koppel er een database aan voor de data en als front gebruik je struts.
Dus geen "applet" maken voor client.

Zie eerdere comments.

Ik denk dat je in 3maanden met twee goed programmeurs gemakkelijk een shell moet kunnen bouwen. Je zal dan een test opstellinge hebben en deze verder ontwikkelen en fine tuning dat zou dan nog een paar maanden kunnen duren, afhankelijk van de eisen die de opdrachtgever. Dus 6maanden ? ofzo.

Tering.....zo lang? Het is een simpele chat applicatie, je hoeft niet een compleet project er van te maken met state/flow-diagrams, tientallen documenten en andere shit.

Kosten; wat betaal je die twee programeurs, wat heb je er voor over...
Probleem zal zijn om twee goed java programmeurs te vinden.

Als je in 'huis' twee goed programeur hebt kost het je dus niets.

Ik denk dat ik zo iets alleen zou kunnen maken in 4 a 6 maanden full time werken.
Je moet natuurlijk ook beveiligingen in bouwen en ander bijkomstige dingen, daar hou ik dus ook rekening mee met mijn schatting een ook met de installatie/aanschaf van de server.

boven staande is 'maar' mijn mening

En "mijn mening" is dat er eigenlijk een spelchecker over bovenstaand gehaald moet worden, want ik heb weinig vertrouwen in de programmeerkunsten van iemand die ZO veel spelfouten maakt in een korte tekst.

[Verwijderd]

Ik ga er van uit dat je het voor een bedrijf doet en niet zo maar wat aan rommeld..

dus ook documentatie !! ja ....
een een paar maanden is niet veel als je voor bedrijven werkt..
Alleen al om alles vast te leggen ben je 1 a 2 maanden bezig

Ik werk aan dit soort dingen de hele dag voor het bedrijf waar ik voor werk dus heb er wel wat ervaring over. Software dat niet gedocumenteerd is heb je niets aan 'is hier een kreet' !!

Als deze opdracht in de hobby sfeer is ..
hmmm
1000+chats + web cam ...
sex site of zo ????????
lol

Als het voor de hobby is kan je dit maken zonder 1 letter of cijfer te programmeren 'google is you best friend'

Maar wil je dit pakket gaat/wil verkopen moet je toch een hele ander weg bewandelen.


Spelfouten... sorry maar ik heb wat beters te doen omdaar op te letten.
Dus sorry voor de fouten ...

[ Voor 11% gewijzigd door Verwijderd op 18-05-2006 11:19 ]

[Janoz]

Erkens schreef op donderdag 18 mei 2006 @ 10:59:

Komop. Ik snap best dat je php met hand en tand wil verdedigen, maar denk ook even na voordat je wat post. Je kunt wel simpel mijn post plakken, maar wat dacht je van de volgende dingen:

• Hoe garandeer je dat er slechts 1 instantie van je master applicatie draait
• Hoe was je van plan binnenkomende verzoeken af te laten handelen door dat master script
• Hoe zorg je ervoor dat het eeuwig lopend masterscript niet de server onderuittrekt aangezien php bedoeld is voor kort lopende request afhandeling en daarom dus geen garbage collection tijdens de uitvoer doet.
• Hoe ga je gegevens uitwisselen tussen het masterscript en je clients.

Accepteer nu eens dat er best wel eens gevallen zouden kunnen zijn waarbij een niet php oplossing gewoon handiger is.

[sig69]

Verwijderd schreef op donderdag 18 mei 2006 @ 10:52:
...
Als je in 'huis' twee goed programeur hebt kost het je dus niets.

Lol... Dus twee programmeurs die een paar maanden bezig zijn kost niets?
2 werkplekken een aantal maanden, salaris, etc... Of werk jij voor nop?

offtopic:
Als je code net zo'n rommeltje is als wat je hier post...

[Verwijderd]

Volgens mij kon data-stroom van je webcam gewoon in java inroepen/ (onhandige woordgebruik)

Kijk ff in je API. Ik had iets gehoord dat je gewoon kon inladen die hap. Maar hoe je dat doet over het internet, al sla je me dood....

[Erkens]

Janoz schreef op donderdag 18 mei 2006 @ 11:16:
Komop. Ik snap best dat je php met hand en tand wil verdedigen, maar denk ook even na voordat je wat post.

Nee, ik wil misverstanden weg werken, die blijkbaar ook bij jou aanwezig zijn

Je kunt wel simpel mijn post plakken, maar wat dacht je van de volgende dingen:

Maar dat is wel de methode die ik destijds had toegepast

[q]
• Hoe garandeer je dat er slechts 1 instantie van je master applicatie draait

Op dezelfde manier als dat je dat met C zou kunnen doen, zoals bijvoorbeeld met een PID file oid

[q]
• Hoe was je van plan binnenkomende verzoeken af te laten handelen door dat master script

Rare vraag, volgens mij denk je echt dat je met PHP geen applicaties kan schrijven, PHP is wel meer dan een simpel script taaltje hoor
Zo heb je bijvoorbeeld sockets die je zou kunnen gebruiken.

[q]
• Hoe zorg je ervoor dat het eeuwig lopend masterscript niet de server onderuittrekt aangezien php bedoeld is voor kort lopende request afhandeling en daarom dus geen garbage collection tijdens de uitvoer doet.

weer zo'n misverstand, PHP is niet alleen geschikt voor het afhandelen van requests, ga er maar van uit dat je minstends hetzelfde kan doen met PHP als dat je met bijvoorbeeld Perl kan doen.

[q]
• Hoe ga je gegevens uitwisselen tussen het masterscript en je clients.

je valt in herhaling

Accepteer nu eens dat er best wel eens gevallen zouden kunnen zijn waarbij een niet php oplossing gewoon handiger is.

o, ik ben er helemaal voor om de right tool te gebruiken, maar als je allen PHP developers binnen je bedrijf hebt is het vaak handiger om dat te gebruiken, dan dat je externe gaat inhuren of je mensen gaat omscholen.

[orf]

http://www.123flashchat.com/

[Janoz]

Erkens schreef op donderdag 18 mei 2006 @ 11:29:
[...]

Nee, ik wil misverstanden weg werken, die blijkbaar ook bij jou aanwezig zijn

Ik weet dondersgoed wat er wel en niet kan met php. Echter weet ik ook wat er met andere oplossingen allemaal wel en niet kan. Als ik een probleem tegenkom bedenk ik 'Hoe ga ik dit oplossen' in tegenstelling tot 'Hoe ga ik dit eens in php oplossen'.

Maar dat is wel de methode die ik destijds had toegepast

Ik zeg niet dat het compleet onmogelijk is, ik zeg alleen dat het zeker niet eenvoudig is

Op dezelfde manier als dat je dat met C zou kunnen doen, zoals bijvoorbeeld met een PID file oid

Fair enough

Rare vraag, volgens mij denk je echt dat je met PHP geen applicaties kan schrijven, PHP is wel meer dan een simpel script taaltje hoor
Zo heb je bijvoorbeeld sockets die je zou kunnen gebruiken.

Hoe zorg je ervoor dat je in een non threaded omgeving als in je masterscript meerdere clients een verbinding kunne krijgen?

weer zo'n misverstand, PHP is niet alleen geschikt voor het afhandelen van requests, ga er maar van uit dat je minstends hetzelfde kan doen met PHP als dat je met bijvoorbeeld Perl kan doen.

Perl is niet de enige keuze mogelijkheid. Kijk daarnaast gewoon eens hoe php gebouwd is. Heb je ergens een free achtige functie gezien? Een php script dat dagen blijft lopen is gewoon vragen om problemen simpel vanwege het feit dat het hiervoor niet bedoeld is.

je valt in herhaling

Nee, niet. Het enige dat je door kunt geven is een stringetje. Connections kun je bijvoorbeeld niet doorgeven.

o, ik ben er helemaal voor om de right tool te gebruiken, maar als je allen PHP developers binnen je bedrijf hebt is het vaak handiger om dat te gebruiken, dan dat je externe gaat inhuren of je mensen gaat omscholen.

Grappig. Ik heb je nog nooit daadwerkelijk op een 'ik ben er helemaal voor om de right tool te gebruiken' opmerking kunnen betrappen.

[Sv3n]

Verwijderd schreef op donderdag 18 mei 2006 @ 11:29:
Volgens mij kon data-stroom van je webcam gewoon in java inroepen/ (onhandige woordgebruik)

Kijk ff in je API. Ik had iets gehoord dat je gewoon kon inladen die hap. Maar hoe je dat doet over het internet, al sla je me dood....

Ja dat kan, maar het kost veel load(clientside) en veel banbreedte, en de api(Java media Framework) is niet goed doorontwikkeld (imo). Versturen kan ook, met rtp, maar zoals gezegd kost aardig wat bandbreedte.

Verwijderd schreef op donderdag 18 mei 2006 @ 10:52:
Ik zou gewoon een browser applicatie maken, dus een web pagina. (struts) geen "applet"

Waarom dat ? Dat is juist niet handig, je krijgt dan altijd delay, een push protocol werkt hiervoor veel beter dan het http (pull) protocol.

[ Voor 6% gewijzigd door Sv3n op 18-05-2006 11:47 ]

[.oisyn]

Erkens schreef op donderdag 18 mei 2006 @ 11:29:
Op dezelfde manier als dat je dat met C zou kunnen doen, zoals bijvoorbeeld met een PID file oid

Dat is ook een halfbakken oplossing, het OS biedt daar veel mooiere methodes voor (global mutexes bijvoorbeeld)

weer zo'n misverstand, PHP is niet alleen geschikt voor het afhandelen van requests, ga er maar van uit dat je minstends hetzelfde kan doen met PHP als dat je met bijvoorbeeld Perl kan doen.

Euh, je gaat hier niet helemaal in op het punt dat Janoz daadwerkelijk aandraagt. PHP leakt als een gek, en dat is gewoon een feit. Meestal heb je daar geen last van juist omdat een php script nogal short lived is (let op, dit is niet hetzelfde als zeggen dat het er niet voor ontworpen is, maar kom op, zelfs jij weet beter - de developers focussen voornamelijk op webapps), maar als een php app lang runt en veel geheugen rondgooit dan ontploft het op een gegeven moment gewoon.

PHP:

$a = new MyObject;
$a->a = new MyObject;
$a->a->a = $a;
$a = 0;
// Hopla, mooie lek. 2 MyObjects in het geheugen waar je niet meer bij kan
// en die niet worden vrijgegeven omdat naar beide objecten nog een referentie bestaat.
// Lang leve reference counting!

[ Voor 14% gewijzigd door .oisyn op 18-05-2006 11:57 ]

[Erkens]

Janoz schreef op donderdag 18 mei 2006 @ 11:41:
Ik weet dondersgoed wat er wel en niet kan met php. Echter weet ik ook wat er met andere oplossingen allemaal wel en niet kan. Als ik een probleem tegenkom bedenk ik 'Hoe ga ik dit oplossen' in tegenstelling tot 'Hoe ga ik dit eens in php oplossen'.

Nee natuurlijk, maar als ik terug kijk naar de topicstart zie ik daar een voorkeur van PHP, dus moet je dat ook gewoon meenemen in je keuze/onderzoek. Waarschijnlijk krijg je dan net als ik destijds onderzocht had problemen met de schaalbaarheid (wij konden destijds op onze server iets van 150 clients "gelijktijdig" afhandelen met PHP)

Hoe zorg je ervoor dat je in een non threaded omgeving als in je masterscript meerdere clients een verbinding kunne krijgen?

kijk, dat zijn betere vragen
daar zijn natuurlijk oplossingen voor, maar voor een chat oplossing is dat niet een heel groot probleem, althans bij ons werkte het ook prima, maar met meer mensen of een erg drukke chat server kan je hier problemen mee krijgen, wat wij deden was gewoon zo kort mogelijk verbinding hebben, dan heb je nergens problemen mee.

Perl is niet de enige keuze mogelijkheid. Kijk daarnaast gewoon eens hoe php gebouwd is. Heb je ergens een free achtige functie gezien? Een php script dat dagen blijft lopen is gewoon vragen om problemen simpel vanwege het feit dat het hiervoor niet bedoeld is.

unset

fyi: onze chatserver draaide minstends 30 dagen prima zonder problemen (daarna moest de server vanwege onderhoud een reboot krijgen, vlak daarna was ik daar weg)

Nee, niet. Het enige dat je door kunt geven is een stringetje. Connections kun je bijvoorbeeld niet doorgeven.

maar dat heb je dan ook niet nodig

Grappig. Ik heb je nog nooit daadwerkelijk op een 'ik ben er helemaal voor om de right tool te gebruiken' opmerking kunnen betrappen.

moet je toch beter opletten, maar sowieso hangt er in PW PRG altijd al een anti-php sfeer, juist vanwege de vele misverstanden die mensen hebben, vaak zijn dat mensen die nog nooit met PHP gewerkt hebben, of alleen kijken naar code van de thuisprutsers.

[Verwijderd]

Erkens schreef op donderdag 18 mei 2006 @ 12:00:
moet je toch beter opletten, maar sowieso hangt er in PW PRG altijd al een anti-php sfeer, juist vanwege de vele misverstanden die mensen hebben, vaak zijn dat mensen die nog nooit met PHP gewerkt hebben, of alleen kijken naar code van de thuisprutsers.

Ik ben geen fan van php omdat het out-of-the-box veel functionaliteit mist die je logischerwijs van een taal, die zich profileert als webtaal, wel mag verwachten. Als ik begin met een webapplicatie wil ik me immers niet eerst bezig houden met workarounds om bepaalde functionaliteiten mogelijk te maken. Tevens vind ik de libraries onduidelijk en zeer slecht naamgegeven. Waar ik voorheen php aanrade voor simpele nieuwssites roep ik tegenwoordig RoR. De meerwaarde van php is zolangzamerhand nul-komma-nul aangezien er andere talen zijn die alles velen malen beter kunnen.

Ik ben het niet eens dat er een vermeende anti-php sfeer hangt vanwege "misverstanden", maar eerder door de feitelijke gemissen van de taal en libraries alsmede de vele betere alternatieven.

[Janoz]

Erkens schreef op donderdag 18 mei 2006 @ 12:00:
Nee natuurlijk, maar als ik terug kijk naar de topicstart zie ik daar een voorkeur van PHP, dus moet je dat ook gewoon meenemen in je keuze/onderzoek. Waarschijnlijk krijg je dan net als ik destijds onderzocht had problemen met de schaalbaarheid (wij konden destijds op onze server iets van 150 clients "gelijktijdig" afhandelen met PHP)

Als ik naar de TS kijk zie ik daar een afweging tussen verschillende oplossingen staan.

kijk, dat zijn betere vragen
daar zijn natuurlijk oplossingen voor, maar voor een chat oplossing is dat niet een heel groot probleem, althans bij ons werkte het ook prima, maar met meer mensen of een erg drukke chat server kan je hier problemen mee krijgen, wat wij deden was gewoon zo kort mogelijk verbinding hebben, dan heb je nergens problemen mee.

In principe zie ik de problemen al van verre aankomen. ALs ik ze echter compleet ontleed voor je uit moet leggen voordat ook jij ze inziet zal ik daar in het vervolg rekening mee houden.

unset

Wie garandeert je dat het geheugen dan ook is vrijgegeven?

fyi: onze chatserver draaide minstends 30 dagen prima zonder problemen (daarna moest de server vanwege onderhoud een reboot krijgen, vlak daarna was ik daar weg)

Dat jullie een chatserver hebben kunnen maken die 30 dagen up was betekend nog niet dat php daadwerkelijk ontwikkeld is om langer dan een paar seconden te draaien.

maar dat heb je dan ook niet nodig

Ligt maar net aan de oplossing. Het is bijvoorbeeld onmogelijk om in php op een normale manier een irc connection pool bij te houden.

moet je toch beter opletten, maar sowieso hangt er in PW PRG altijd al een anti-php sfeer, juist vanwege de vele misverstanden die mensen hebben, vaak zijn dat mensen die nog nooit met PHP gewerkt hebben, of alleen kijken naar code van de thuisprutsers.

Persoonlijk heb ik eerder het tegenovergestelde idee. Bij elk probleem wordt gelijk van een php oplossing uit gegaan. Een anti-php sfeer lijkt me daarom erg onwaarschijnlijk. Ik heb jou daarintegen nog nooit ergens kunnen betrappen op een "nee, dat kun je beter in X doen ipv php omdat dat veel handiger is".

[ Voor 4% gewijzigd door Janoz op 18-05-2006 12:19 ]

[CyBeR]

CyBeR schreef op vrijdag 05 mei 2006 @ 00:16:
Ik zou 's kijken naar Comet. http://alex.dojotoolkit.org/?p=545.

Om mezelf maar 's te quoten. Het Comet principe is exact voor dit soort shit ontwikkeld: low-latency event-based data van server naar client, zonder polling. Apache ondersteunt het nog niet (komt er aan), maar Twisted wel. Twisted is dan wel python, maar dat mag weinig uitmaken omdat:

• Python voor PHP devvers vrij simpel te leren is
• PHP voor dit soort taken toch compleet ongeschikt is, tenzij je in de CLI php een complete webserver gaat maken.

[ Voor 4% gewijzigd door CyBeR op 18-05-2006 13:23 ]

[André]

Verwijderd schreef op donderdag 18 mei 2006 @ 11:15:
Ik ga er van uit dat je het voor een bedrijf doet en niet zo maar wat aan rommeld..

Tweakers.net is ook een bedrijf, en hun core business draait op PHP. Volgens jou werkt dat niet, is het onbetrouwbaar en moeten ze over naar JAVA

[.oisyn]

Erkens schreef op donderdag 18 mei 2006 @ 12:00:
unset

Dat gaat je niet helpen, zie de code in mijn vorige reactie ([rml].oisyn in "[ AJAX] Chat applicatie, advies gevraagd"[/rml])

[Verwijderd]

ok .. new try

Als je het werk wil uitbesteden dat maak ik op door je vraag stellingen.
Dan zou ik gewoon naar een paar bedrijven gaan die dit soort applicaties hebben gebouwd of kunnen bouwen en kijken wat zij jullie kunnen bieden en dan weet je ook direct de prijs.

Op dit forum zal je wel schijnlijk wel allerlij antwoorden krijgen maar daar zal je weinig aan hebben als je op kort temijn de applicatie wil gaan gebruiken. Als ik jou was zal ik eerst opzoek gaan naar een paar programeurs/bedrijf die dit willen gaan bouwen voor jullie deze zullen wel verder adviseren wat het besten is.
Denk dat deze discusie weinig zin heeft.

[Soultaker]

Erkens reageerde oorspronkelijk op mijn bericht; ik had me voorgenomen er vandaag op te reageren, maar ik zie dat Janoz mijn stelling al perfect verdedigd heeft, dus dat ga ik niet over doen.

Wel wil ik opmerken dat je met PHP een stuk of vier executiemodi hebt en dat de problemen steeds verschillen:
• module van een forking webserver (meest gebruikelijk met Apache);
• module van een multithreading webserver;
• CGI-applicatie;
• FastCGI-applicatie;
Elke heeft zo zijn voor- en nadelen. Het essentiële probleem is communicatie tussen verschillende requests; eigenlijk is dat bij alle opties problematisch. Bij de eerste en derde moet je sowieso communicatie tussen processen doen (erg lastig); bij de tweede en vierde tussen threads (ook erg vervelend).

Wat mij nog het makkelijkste lijkt (let wel, als je het via HTTP wil doen, wat me ueberhaupt niet handig lijkt) is een FastCGI applicatie die door de programmeur aangestuurd wordt (en dus niet, zoals PHP doet, impliciet door het framework afgehandeld wordt). Dit is de standaardmanier om FastCGI te gebruiken in C/C++ (en ook in scripttalen als Perl en Python) maar in PHP kan dit (voor zover ik weet) helemaal niet, omdat er helemaal geen FastCGI library/extentie is voor PHP! De meest geschikte situatie is dus al niet beschikbaar.

Niemand bestrijdt dat je door allerlei restricties op executietijd en geheugengebruik uit te schakelen en met een hele zwik aan extensies voor shared memory en synchronisatieprimitieven iets werkends zou kunnen bouwen in PHP, maar daarmee is niet gezegd dat het handig is.

Erkens schreef op donderdag 18 mei 2006 @ 12:00:
moet je toch beter opletten, maar sowieso hangt er in PW PRG altijd al een anti-php sfeer, juist vanwege de vele misverstanden die mensen hebben, vaak zijn dat mensen die nog nooit met PHP gewerkt hebben, of alleen kijken naar code van de thuisprutsers.

Dat is echt onzin. Ik heb heel veel PHP gebruikt, met veel plezier, omdat PHP erg geschikt is voor de taak waarvoor het ontworpen is: dynamisch webdocumenten genereren. De reden dat PHP zo populair is is simpelweg dat het, ondanks de vele bugs en tekortkomingen, uitermate geschikt is voor dat doel. Daar is niets mis mee.

Dat PHP een beperkt toepassingsgebied heeft, is geen misverstand, maar simpelweg een constatering van iemand die ook andere technieken gebruikt heeft (CGI, FastCGI, webservermodules) en de mogelijkheden en beperkingen ervan heeft ervaren. Het idee dat PHP maar overal voor gebruikt moet worden is juist een misverstand dat ontstaat doordat veel mensen simpelweg geen andere technieken kennen.

[killercow]

Soultaker schreef op donderdag 18 mei 2006 @ 15:49:
Dit is de standaardmanier om FastCGI te gebruiken in C/C++ (en ook in scripttalen als Perl en Python) maar in PHP kan dit (voor zover ik weet) helemaal niet, omdat er helemaal geen FastCGI library/extentie is voor PHP! De meest geschikte situatie is dus al niet beschikbaar.

Er is wel degelijk een fastcgi module voor php, en je kunt ook wel degelijk vars en objecten in shared mem zetten (en zo dus global gebruiken).

De anti-php sfeer hier is bij een groot deel van mensen hier inderdaad ongegrond, en bij de rest is het vaak dat ze denken dat code in java het probleem veel eleganter kunnen oplossen.

Nu is dat vaak ook wel zo, Maar is het projectje veels te klein, zal de learning curve voor een nieuwe taal + paradigm veel te hoog zijn en zullen support problemen en server problemen zo veel problemen geven in de topics waar het in geroepen wordt dat jouw eigen argument hier tegen gebruikt kan worden.
Soms is de mooiste oplossing niet mogelijk.

[Sv3n]

killercow schreef op donderdag 18 mei 2006 @ 21:48:
[...]
De anti-php sfeer hier is bij een groot deel van mensen hier inderdaad ongegrond, en bij de rest is het vaak dat ze denken dat code in java het probleem veel eleganter kunnen oplossen.

Niks anti-php sfeer, de ts vraagt om advies voor een chat systeem, chatten is real time, real time wil je met een push protocol doen, niet met een pull protocol(http). Dit wordt hier gewoon duidelijk gemaakt, dat heeft helemaal niks met een anti-php sfeer te maken maar met de beste oplossing en dat is php zeker niet.

[Soultaker]

killercow schreef op donderdag 18 mei 2006 @ 21:48:
Er is wel degelijk een fastcgi module voor php

Waar dan? Op de officiële FastCGI website is 'ie niet te vinden. Merk op dat ik het expliciet niet heb over de FastCGI suppert in de PHP-interpreter zelf (die overigens prima werkt, maar niet de voordelen biedt waar ik aan refereerde omdat alle requests daarmee juist weer gescheiden worden).

De anti-php sfeer hier is bij een groot deel van mensen hier inderdaad ongegrond

Wat bedoel je met een 'anti-php sfeer'? Dat mensen die ook verstand hebben van andere programmeertalen PHP als ongeschikt zien voor het bouwen van een chatserver voor duizenden clients? Dat noem ik geen 'anti-php sfeer' maar gezond verstand.

Dit standpunt wordt nog eens onderbouwd door het feit dat alle grote (maar ook niet zo heel grote) aanbieders van chatapplicaties (zie verder in het topic voor een hele lijst) géén PHP gebruiken voor die server, ondanks dat PHP zelf wél veel gebruikt wordt. Als de constatering 'ongegrond' is, waar zijn dan die IRC servers geschreven in PHP?

Heb je zelf wel eens geprobeerd in hoeverre PHP schaalt? Heb je wel eens geprobeert met PHP duizende concurrente connecties af te handelen én die bovendien met elkaar laten communiceren?

Maar is het projectje veels te klein, zal de learning curve voor een nieuwe taal + paradigm veel te hoog zijn en zullen support problemen en server problemen zo veel problemen geven in de topics waar het in geroepen wordt dat jouw eigen argument hier tegen gebruikt kan worden. Soms is de mooiste oplossing niet mogelijk.

Een website met duizenden gebruikers tegelijk online is niet klein. PHP is niet zozeer 'niet de mooiste oplossing'; het is géén oplossing - als de TS hiervoor PHP gebruikt ik hem garanderen dat het nooit gaat werken (dat zei ik in het begin al). Als hij (bijvoorbeeld) Java leert en een IRC server installeert, zijn zijn kansen een stuk groter.

[ Voor 15% gewijzigd door Soultaker op 18-05-2006 22:03 ]

[killercow]

Sv3n schreef op donderdag 18 mei 2006 @ 21:52:
[...]

Niks anti-php sfeer, de ts vraagt om advies voor een chat systeem, chatten is real time, real time wil je met een push protocol doen, niet met een pull protocol(http). Dit wordt hier gewoon duidelijk gemaakt, dat heeft helemaal niks met een anti-php sfeer te maken maar met de beste oplossing en dat is php zeker niet.

Nope, in dit topic niet, hier is het ook volledig terecht, (als blijft de uitdaging om het via http te doen leuk )

[NMe]

killercow schreef op donderdag 18 mei 2006 @ 21:48:
Er is wel degelijk een fastcgi module voor php, en je kunt ook wel degelijk vars en objecten in shared mem zetten (en zo dus global gebruiken).

Globaal in hetzelfde bestand ja. Als je iets globaal beschikbaar wil maken in de gehele applicatie zul je toch echt een vorm van persistentie (database, cookies, sessies) moeten gaan gebruiken.

De anti-php sfeer hier is bij een groot deel van mensen hier inderdaad ongegrond, en bij de rest is het vaak dat ze denken dat code in java het probleem veel eleganter kunnen oplossen.

Net als Soultaker gebruik ik PHP met liefde voor die projecten waarvoor het goed is: simpele websites en andere, niet-gecompliceerde dynamische content. PHP is simpelweg nooit ontworpen met de gedachte dat het als een applicatie moet blijven draaien tot Sint Juttemis. Dat er wel voorzieningen zijn getroffen waardoor het kàn op een al dan niet ranzige manier wil nog niet zeggen dat het ervoor bedoeld is, en dat er niet talloze talen zijn die er beter voor geschikt zijn.

PHP is een van de weinige talen waarvan ik echt durf te zeggen dat ik hem beheers. Daarmee bedoel ik dat ik weet wanneer ik welke taalelementen en standaardfuncties al dan niet kan/moet gebruiken, en wat de bekende valkuilen zijn. Juist daarom vind ik dat ik prima kan oordelen over PHP, en mijn oordeel is dat het door teveel mensen verkeerd wordt toegepast. Gebruik lekker de taal/omgeving die het meest geschikt is voor een opdracht en neem niet elke keer maar weer PHP simpelweg omdat het kan. Ik kan ook op handen en voeten naar mijn werk gaan, maar dat is nog geen reden om het te doen.

Nu is dat vaak ook wel zo, Maar is het projectje veels te klein, zal de learning curve voor een nieuwe taal + paradigm veel te hoog zijn en zullen support problemen en server problemen zo veel problemen geven in de topics waar het in geroepen wordt dat jouw eigen argument hier tegen gebruikt kan worden.
Soms is de mooiste oplossing niet mogelijk.

Als je dit altijd maar weer als argument neemt leer je nooit een taal bij. Het leren van een programmeertaal stelt niks voor. Granted, je kent de best practices en bekende valkuilen niet of niet allemaal, maar er is referentiemateriaal genoeg te vinden. Na een paar weken ken je, als je al programmeerervaring hebt, echt wel genoeg van een taal om er een applicatie als dit in te schrijven.

[killercow]

-NMe- schreef op donderdag 18 mei 2006 @ 22:04:
[...]

Globaal in hetzelfde bestand ja. Als je iets globaal beschikbaar wil maken in de gehele applicatie zul je toch echt een vorm van persistentie (database, cookies, sessies) moeten gaan gebruiken.

[...]

Global, was misschien niet het juiste woord,

Persisten dan, als script A sluit , kan script B er alsnog bij, (wat ook weer een probleem kan zijn op non-dedicated machines, maar ja daar kunnen de meeste got users ook geen eigen java of c++ app op installeren.

Je kunt een massieve array of object gewoon sharen tussen verschillende php instances/requests. Of het ook echt helemaal supported is, geen clue. het werkt.

[MisterData]

Ik heb in AJAX iets soortgelijks gemaakt, zie www.ech-wel.nl Dat ding rechts refresht via AJAX iedere 10 seconden, maar dat kan ook sneller natuurlijk.

[Bigs]

Ik heb voor http://www.neteye.nl/ (no spam intended, jammergenoeg kun je niet chatten zonder je aan te melden) ook een simpele AJAX-chat gemaakt. Hij bestaat uit een Ruby on Rails controller van 120 regels en een javascriptje van 140 regels.. 1 gezamelijke chatbox en ondersteuning voor privéchats. Ik smijt alle chatberichten met een chatbox_id in een database. Elke keer als de client een request voor een update doet stuurt de server alle berichten die die client mag zien (dus van chat sessies waar hij bij betrokken is), plus het hoogste id dat op dat moment in de database staat. Dat stuurt die client vervolgens met de volgende update zelf weer mee.

Het werkt snel, clean en schaalt beter dan je zou verwachten. De load van de Ajax-requests stelt werkelijk niets voor. We hebben het met 100 users getest en dat gaf geen problemen (mysql houdt de hele chat-tabel vanzelf in zijn geheugen). Hierbij moet ik wel zeggen dat we in de mysql tabel elke 5 minutena alle oude berichten er uit gooien. Of het met 1000 chattende users tegelijk ook nog soepel werkt durf ik niet te zeggen, maar ik kan me niet voorstellen dat een iframe beter werkt.

Als je geen database wilt gebruiken zou ik in plaats van op vreemde manieren variabelen te cachen zou ik gewoon kiezen voor memcached, volgens mij moet dat ook wel met PHP werken.

[Verwijderd]

Bigs schreef op vrijdag 19 mei 2006 @ 02:07:
volgens mij moet dat ook wel met PHP werken.

Tsja, je kunt het ook in assembly proberen en misschien zelfs in brainfuck. Maar je kiest toch liever een taal die uit het doosje geschikt is voor de taak?

[Bigs]

Verwijderd schreef op vrijdag 19 mei 2006 @ 08:54:
[...]

Tsja, je kunt het ook in assembly proberen en misschien zelfs in brainfuck. Maar je kiest toch liever een taal die uit het doosje geschikt is voor de taak?

Wat is dat nou weer voor lompe opmerking? Ik bedoel dat ik vermoed dat PHP ook ondersteuning voor memcached heeft, wat dus zo is. Ga ergens anders trollen svp.

[Mithrandir]

Bigs schreef op vrijdag 19 mei 2006 @ 12:16:
[...]


Wat is dat nou weer voor lompe opmerking? Ik bedoel dat ik vermoed dat PHP ook ondersteuning voor memcached heeft, wat dus zo is. Ga ergens anders trollen svp.

Zelfs al heeft PHP daarvoor ondersteuning, de persistent datalaag is niet het grootste probleem waar je tegenaanloopt...

Zoals al veel eerder en vaker hier is gezegd: Je hebt een PUSH protocol nodig, geen PULL protocol. PHP kán geen push geven naar de client, dus je bent veel beter af met java.

[NMe]

Bigs schreef op vrijdag 19 mei 2006 @ 12:16:
Wat is dat nou weer voor lompe opmerking? Ik bedoel dat ik vermoed dat PHP ook ondersteuning voor memcached heeft, wat dus zo is. Ga ergens anders trollen svp.

Ik zie geen troll? Hij zegt -terecht- dat je de taal moet gebruiken die het meest geschikt is voor een probleem. En dat is lang niet altijd PHP.

[Erkens]

Mithrandir schreef op vrijdag 19 mei 2006 @ 12:33:
PHP kán geen push geven naar de client, dus je bent veel beter af met java.

bullshit, je kan prima pushen via een http verbinding die je open laat staan, wat met PHP erg eenvoudig te implementeren is.

[NMe]

Erkens schreef op vrijdag 19 mei 2006 @ 12:37:
bullshit, je kan prima pushen via een http verbinding die je open laat staan, wat met PHP erg eenvoudig te implementeren is.

Ja, en je kan ook prima dikke stront door een trechter duwen. Het protocol is er gewoon niet op gemaakt, punt.

[.oisyn]

Erkens schreef op vrijdag 19 mei 2006 @ 12:37:
[...]

bullshit, je kan prima pushen via een http verbinding die je open laat staan, wat met PHP erg eenvoudig te implementeren is.

En ga je ook nog in op de andere opmerkingen en vragen die in deze draad aan jou gericht zijn of laat je het er maar bij?

[Erkens]

-NMe- schreef op vrijdag 19 mei 2006 @ 12:38:
Ja, en je kan ook prima dikke stront door een trechter duwen. Het protocol is er gewoon niet op gemaakt, punt.

maar soms heb je geen keus omdat je te maken hebt met strenge bedrijfs firewalls/proxyserver waar je wel doorheen moet en is HTTP de beste enige keus.

.oisyn schreef op vrijdag 19 mei 2006 @ 12:47:
En ga je ook nog in op de andere opmerkingen en vragen die in deze draad aan jou gericht zijn of laat je het er maar bij?

nee, jullie manier van reageren tegen mij staat me niet aan, ik had me voor genomen gewoon niet meer te reageren, maar ik zie dat ik me niet altijd kan inhouden. Ik blijf nu wel weg uit dit topic

[NMe]

Erkens schreef op vrijdag 19 mei 2006 @ 12:49:
maar soms heb je geen keus omdat je te maken hebt met strenge bedrijfs firewalls/proxyserver waar je wel doorheen moet en is HTTP de beste enige keus.

Soms is bij lange na niet altijd.

nee, jullie manier van reageren tegen mij staat me niet aan, ik had me voor genomen gewoon niet meer te reageren, maar ik zie dat ik me niet altijd kan inhouden. Ik blijf nu wel weg uit dit topic

Onze manier van reageren? Je bedoelt het gebruiken van argumenten om aan te tonen dat jouw argumenten simpelweg niet kloppen?

[.oisyn]

Tja, ik zie geen geflame in de topic en iedereen draagt gewoon argumenten aan. Als je daar niet eens gewoon op in kan gaan heeft een discussie idd weinig nut. Ook zie ik geen verschil tussen deze draad en al die andere topics op GoT waarin jij wél mee blijft discussieren, behalve dan dat je argumenten in die andere topics wat valider zijn in deze (toeval? ik denk het niet). Typisch dat je dan ook meteen op de verpakking gaat reageren ipv op de inhoud.

[ Voor 10% gewijzigd door .oisyn op 19-05-2006 13:27 ]

[Verwijderd]

Erkens schreef op vrijdag 19 mei 2006 @ 12:49:
nee, jullie manier van reageren tegen mij staat me niet aan, ik had me voor genomen gewoon niet meer te reageren, maar ik zie dat ik me niet altijd kan inhouden. Ik blijf nu wel weg uit dit topic

Ik voel mij geschonden wat betreft mijn copyright rechten

[flashin]

Ik ga er van uit dat je het voor een bedrijf doet en niet zo maar wat aan rommeld..

dus ook documentatie !! ja ....
een een paar maanden is niet veel als je voor bedrijven werkt..
Alleen al om alles vast te leggen ben je 1 a 2 maanden bezig

Oh nee dan is een paar maanden niet veel, wat ben je dan voor een persoon.
Het gaat om een simpele chat dus je hebt helemaal geen documentatie nodig waar je 1 a 2 maanden fulltime aan werkt, wat ik me ook niet echt kan voorstellen. Ik schrijf ook vrij uitgebreide rapporten maar langer dan een dag/paar dagen zie je me het niet doen.

Spelfouten... sorry maar ik heb wat beters te doen omdaar op te letten.
Dus sorry voor de fouten ...

Ik begrijp wel waarom je dus zo lang met je documentatie bezig bent...

Afijn. IRC is nog niet zo heel veel genoemd, maar wel een handige oplossing voor jouw probleem. Waarom het hele wielprotocol opnieuw uitvinden?
Wat je nog moet implementeren is het webcam gedeelte voor de privechats. Maar daar moet je wel goed over nadenken,
Hoeveel man kunnen tegelijk de webcam zien?
Gaan de webcambeelden p2p of ook nog over de server?
etc.
etc.

Kijk eerst naar andere voorbeelden van de implementatie van het IRC protocol in een (java)applicatie, en de implementatie van een webcam mogelijkheid

[Verwijderd]

Heb je wel een een applicatie gemaakt voor een extern bedrijf?
Weet je wat er allemaal om de hoek komt kijken.

Zo te lezen zitten hier veel hobby programmeur maar waarschijnlijk weinig programeur die echt ervaring hebben in het bedrijfs leven. (niet negatief bedoelt)
Ik word ook gek van al die vergaderingen enz.. maar ja zo gaan die dingen eenmaal.

Soms wordt er alleen al 6maanden gepraat om de opdracht goed te beschrijven tussen de verschillende partijen, dead lines afspreken en aansprakelijkheden contracten opstellen notarisen inschakelen ter controle enz...
En dat kunnen dus ook hele kliene/simpele programmas zijn die je in 2 dagen schrijft.

Ik ga er dus van uit dat het niet voor de hobby sfeer is als in eerder emails van mij.

Hij wil waarschijnlijk de software gaan verkopen/leasen als ik het goed begrijp.
Dus dan kan je niet gebruik maken van bestaande software dat heet stelen.
Dus je moet het wiel wel op niet uitvinden als je niet aangeklaagd wil worden

Man, let toch eens een beetje op je spelling, dit is niet te lezen.

[ Voor 30% gewijzigd door whoami op 19-05-2006 15:43 ]

[Verwijderd]

welk bedrijf is dat als ik vragen mag?

[RobIII]

Verwijderd schreef op vrijdag 19 mei 2006 @ 15:19:
Hij wil waarschijnlijk de software gaan verkopen/leasen als ik het goed begrijp.
Dus dan kan je niet gebruik maken van bestaande software dat heet stelen.
Dus je moet het wiel wel op niet uitvinden als je niet aangeklaagd wil worden

Je spreekt jezelf tegen Je mag geen bestaande software gebruiken? én je moet het wiel niet opnieuw uitvinden

Tuurlijk mag je bestaande software gebruiken mits je je aan de EULA / licentievoorwaarden houdt en voldoende licenties aanschaft. En tuurlijk mag dat ook commercieel.

Jammer hoe een draad als deze kan ontsporen in complete offtopic gebazel over PHP e.d. Als je diep in je hart kijkt weet je als PHP-er ook wel dat het niet erg geschikt is om een chat applicatie (PUSH) in te bouwen zonder daar allerlei hacks op los te hoeven laten (zoals hierboven veel beschreven hacks). Om die lijn door te trekken: Ik ben zelf redelijk doorgewinterd ASP-er en zou, zeker met een singleton objectje bijvoorbeeld, easy een chatapplicatie in mekaar kunnen flansen. Of dat echter werkbaar is is een tweede. Ik zou het iig niet doen in ASP. Ikzelf zou gewoon gaan voor IRC, jabber of iets in die trend. En anders kijk eens naar de SDK voor Messenger (geen idee of dat iets is, ik roep maar wat).

[ Voor 39% gewijzigd door RobIII op 19-05-2006 15:31 ]

[ThunderNet]

Als ik jou was, zou ik kijken naar iets als een webservice (makkelijk te realiseren in .NET (met c# bijv.) En in die webservice een aangepaste versie van het IRC protocol implementeren (met webcam support)

Die webservice kun je weer gebruiken om je pagina's mee op te bouwen wat dan weer wel in php / asp.NET zou kunnen.

[Bigs]

-NMe- schreef op vrijdag 19 mei 2006 @ 12:34:
[...]

Ik zie geen troll? Hij zegt -terecht- dat je de taal moet gebruiken die het meest geschikt is voor een probleem. En dat is lang niet altijd PHP.

De TS geeft aan dat hij het probleem met PHP wil oplossen..

[gorgi_19]

ThunderNet schreef op vrijdag 19 mei 2006 @ 15:37:
Als ik jou was, zou ik kijken naar iets als een webservice (makkelijk te realiseren in .NET (met c# bijv.) En in die webservice een aangepaste versie van het IRC protocol implementeren (met webcam support)

Die webservice kun je weer gebruiken om je pagina's mee op te bouwen wat dan weer wel in php / asp.NET zou kunnen.

Een webservice? Waarom? Je creeert gruwelijk veel extra overhead?

[whoami]

gorgi_19 schreef op vrijdag 19 mei 2006 @ 19:05:
[...]

Een webservice? Waarom? Je creeert gruwelijk veel extra overhead?

Omdat webservices hip zijn, en alles waar een webservice gebruikt wordt sexy en goed is; toch ?

[flashin]

Heb je wel een een applicatie gemaakt voor een extern bedrijf?
Weet je wat er allemaal om de hoek komt kijken.

Zo te lezen zitten hier veel hobby programmeur maar waarschijnlijk weinig programeur die echt ervaring hebben in het bedrijfs leven. (niet negatief bedoelt)
Ik word ook gek van al die vergaderingen enz.. maar ja zo gaan die dingen eenmaal.

Soms wordt er alleen al 6maanden gepraat om de opdracht goed te beschrijven tussen de verschillende partijen, dead lines afspreken en aansprakelijkheden contracten opstellen notarisen inschakelen ter controle enz...
En dat kunnen dus ook hele kliene/simpele programmas zijn die je in 2 dagen schrijft.

Nofi dat is (bijna) het enige wat ik doe, maar als je met zo'n logge organisatiestructuur (EN waarschijnlijk ook je ontwikkelingsmethode) werkt vind ik het vreemd dat je uberhaupt al klanten kan vinden die gek genoeg zijn om met jou samen te werken.
Eer je product af is ben je een aantal jaar verder..

En om daarnaast je rapporten in te leveren in zo'n Nederlands. (als je dyslectisch bent, nofi.. maar dit is wel heel erg)

[ Voor 4% gewijzigd door flashin op 19-05-2006 19:17 ]

[Creepy]

Bigs schreef op vrijdag 19 mei 2006 @ 18:22:
[...]


De TS geeft aan dat hij het probleem met PHP wil oplossen..

Hij vraagt daarnaast ook naar de voor en nadelen van PHP in zijn geval

[Verwijderd]

whoami schreef op vrijdag 19 mei 2006 @ 19:14:
[...]


Omdat webservices hip zijn, en alles waar een webservice gebruikt wordt sexy en goed is; toch ?

[edit] Als ik chuxiej was, zou ik maximale synergie zoeken door een web 2.0 oplossing en webservices te combineren! Oh, in Ruby on Rails natuurlijk, anders is je project bij voorbaat mislukt.

[ Voor 32% gewijzigd door Verwijderd op 20-05-2006 13:58 ]

[flowerp]

André schreef op donderdag 18 mei 2006 @ 14:43:
[...]

Tweakers.net is ook een bedrijf, en hun core business draait op PHP. Volgens jou werkt dat niet, is het onbetrouwbaar en moeten ze over naar JAVA

Maar zou Tweakers.net vandaag als ze overnieuw begonnen nog steeds expliciet voor PHP kiezen?

Ik zeg niet dat het altijd zo is, maar dikwijls zie je dat ooit eens iemand wat inelkaar prutste in PHP wat aansloeg kwa concept. Iets wat oorspronkelijk als klein dingetje was bedoeld groeit uit tot iets enorms, zodat je niet meer zomaar even van techniek kan omschakelen ondanks dat iedereen baalt van de keuzes die in het begin zijn gemaakt.

Neem nu ook bijvoorbeeld hyves.nl. Dat was eigenlijk ook maar een klein bij productje van het eigenlijke bedrijfsdoel (iets met een connectie netwerk tussen mobiele telefoons geloof ik). Toen groeide het opeens enorm, en nu zitten ze vast aan een techniek (PHP) die ze zelf ook een "kut taaltje" noemen, maar het is te groot gegroeid om even te verwisselen. Momenteel hebben ze naar ik begreep enkele 100'en (!) servers nodig om de boel in de lucht te houden. Nu weet ik natuurlijk niet exact welke enorm hoge load hyves heeft, maar het lijkt me dat je met andere platformen (zoals Java) waar diverse levels van caching wat makkelijker te realiseren zijn, je toch niet zo waanzinnig veel hardware nodig zou hebben.

[NMe]

PHP is nog steeds prima voor het doel waarvoor het meestal toegepast wordt, en het doel waarvoor het ook ontwikkeld wordt: websites. De taal heeft wat tekortkomingen (waarvan er gelukkig veel uit de wereld geholpen gaan worden in PHP 6), maar het is aan de programmeur om te zorgen dat die tekortkomingen de applicatie niet benadelen. Een programmeur die weet waar hij mee bezig is en gewoon netjes programmeert zal niet snel veel last ondervinden van PHP.

Ik denk dat de keuze van Tweakers.net voor PHP geen stomme keuze is, die waarschijnlijk weer gemaakt zou worden als Femme vandaag besloot helemaal opnieuw te beginnen. Tweakers.net is dan ook in de eerste plaats een website en geen chatserver.

[flowerp]

-NMe- schreef op zaterdag 20 mei 2006 @ 23:07:
PHP is nog steeds prima voor het doel waarvoor het meestal toegepast wordt, en het doel waarvoor het ook ontwikkeld wordt: websites.

Moet dat niet eigenlijk zijn -kleine- websites?

Een klein homepage'je met wat server-side dynamiek erin is waarvoor PHP oorspronkelijk ontwikkeld was. Bij grotere (enterprise) systemen kom je al gauw in de knoei met PHP omdat je essentiele scopes mist, het gebruik van globale variabelen (binnen een requests) uberhaupt mogelijk is en nog gestimuleerd wordt ook, er geen (long running) services kunnen draaien, het platform het gebruik van business logic gemixed met view code stimuleerd, er nog steeds geen goede refactor tools zijn en uberhaupt geen echte profesionele IDEs, de community het gebruik van design patterns en architectuur belachelijk vind, er geen compiler support is die je wijst op type of syntax fouten, en velen andere dingen.

In deze thread was het standpunt natuurlijk overduidelijk: chatten via Http is onzinnig, en sinds PHP zich alleen op http verkeer kan richten is chatten met PHP onzinnig.

Waar ik hier op in ga zijn de andere genoemde nadelen waarom je eigenlijk voor grote projecten geen PHP zou moeten willen gebruiken. Net zoals assembly is php een turing complete taal. In essentie kun je er dus elk algortime mee uitdrukken. In de praktijk, en zeker bij grote projecten, speelt dingen als onderhoud en uitbreidbaarheid een enorm grote rol. 1 van de puntjes wat zo fout is aan PHP (noemde ik al boven) is dat het het gebruik van business logic midden in pagina's stimuleerd. Dat maakt hergebruik onmogelijk. Stukjes code moeten daarom telkens gecopieerd worden, wat de onderhoudbaarheid enorm verslechterd.

Natuurlijk, PHP -dwingt- je niet om dat de toen, maar stimuleerd het wel. Je moet al een heel erg gediciplineerde programmeur zijn om het niet te doen. Kijk je naar profesionele oplossingen als Java en .NET, dan ontmoedigd de hele opbouw van dit platform (in de huidige versies tenminste!) deze uiterst bedenkelijke praktijk. In PHP is het echter de normaalste zaak van de wereld. Sterker nog, de gemiddelde PHP programmeur staat je met open mond aan te gapen als je zegt dat je geen business logic midden op een pagina moet gaan zetten.

Vergeet ook niet dat een taal niet alleen een kale syntax specificatie is. Een taal is meer dan alleen een koude BNF spec. En zelfs een platform is meer dan alleen een API. Een platform wordt omgeven door een cummunity waarin bepaalde idealen, motto's en werkwijzen aangehangen worden. Dit komt tot uitting in de voorbeelden, boeken, documentatie, websites en fora om de taal heen.

Nu heeft PHP, mischien gedeeltelijk nog niet eens te wijten aan de kale syntax zelf, een community om zich heen die de prutser de hemel in prijst en profesionals met hun zware opleidingen de grond in stampt. Natuurlijk zijn er ook een aantal profs die (al dan niet noodgedwongen) met PHP werken, maar de meerderheid van de PHP community hangt wel dergelijke gedachtes aan. Als prof zijnde is het op z'n minst bedenkelijk als je je dus vrijwillig in deze wereld wilt gaan begeven. Het is alsog je als prof wielrenner een fiets bij de ALDI koopt. Natuurlijk zal de ALDI af en toe best leuke fietsen hebben en een goede wielrenner zal ook op een ALDI fiets hard kunnen gaan, maar de echte prof gebruikt gewoon heel ander materiaal.

[NMe]

Je gaat er in je post nogal prat op dat de PHP-community niet weet waar ze mee bezig is. Dat klopt; veel mensen die PHP gebruiken hebben totaal geen benul van programmeren en begaan al de blunders die jij noemt regelmatig. Maar is dat nu een probleem voor een bedrijf? Maakt dat de taal klote? Een bedrijf dat de keuze maakt voor PHP moet ook de keuze kunnen maken om netjes te programmeren. Een goeie programmeur zal design patterns toepassen waar mogelijk (en nodig) en code en layout zoveel mogelijk scheiden. Een goeie programmeur houdt zijn code onderhoudbaar en uitbreidbaar. Dit zijn allemaal dingen die niet taalafhankelijk zijn (althans, niet in dit geval) maar programmeurafhankelijk.

Het feit dat je nu op deze website zit, die door zoveel mensen actief bezocht wordt, bewijst maar weer dat PHP prima toepasbaar is, ook op grotere schaal. De enige vereiste is dat de programmeur weet waarmee hij bezig is.

[DRAFTER86]

Ik ben zelf nu een paar dagen aan het stoeien met Bribble.
Een java server met een flash client. Beide volledig opensource. Zeker niet bugvrij maar redelijk overzichtelijk geschreven en niet erg ingewikkeld. Dit is in ieder geval het beste wat ik tot nu toe ben tegengekomen.
Als je echt nul komma nul java-kennis hebt is het misschien iets te hoog gegrepen...

[flowerp]

-NMe- schreef op zondag 21 mei 2006 @ 00:25:
Een goeie programmeur houdt zijn code onderhoudbaar en uitbreidbaar. Dit zijn allemaal dingen die niet taalafhankelijk zijn (althans, niet in dit geval) maar programmeurafhankelijk.

Gedeeltelijk; een taal kan juist heel veel ondersteuning bieden. Feitelijk zijn alle constructies die met organisatie te maken hebben direct hier aan gerelateerd. Neem basis dingen als functies, classes, packages, assemblies het wel of niet toestaan van globale variabelen, namespaces, aliasses, (web) componenten en typing. Dit zijn elementen die een taal niet biedt om de uitdrukking kracht te vergroten, maar om de beheersbaarheid te vergroten. In zekere zin zijn deze elementen beperkent. In assembly kon je gewoon een hele reeks instructies achter elkaar zetten. In C -moest- alle codes in functies onderverdeeld worden, en in Java -moet- alle code in zowel een functie als een classe staan en in veel gevallen ook in package. Vervolgens -moet- elke variable een type hebben. In Java EE 5 word je voor de default view technology (JSF) min of meer gedwongen om het MVC pattern te volgen.

Al deze 'dwang' mis je in PHP.

Mede daarom is PHP zo'n enorm lamer magner, en vinden lamers -echt- dat PHP beter is. Ze snappen niet dat alle deze dingen juist goed zijn, dat ze gebasseerd zijn op best practices. Veel PHP'ers (let op, niet alle!) zijn net kleine kinderen; ze huilen om en protesteren tegen de dingen die eigenlijk goed voor ze zijn, alleen omdat ze nog niet volwassen genoeg zijn om de voordelen op waarde te schatten.

Je weet zelf waarschijnlijk net zo goed als ik dat zodra de taal dingen niet afdwingt, er altijd toch een of andere gek in je team is die rare dingen gaat doen. Jij zegt terecht dat de programmeur moet weten waarmee ie bezig is, maar hoe weet ik dat al mijn collega's dat inderdaad altijd zijn? Net zoals assembly biedt PHP te veel vrijheid. Programmeurs zullen daar altijd (onbewust of niet) misbruik van maken.

De kans dat ik bijvoorbeeld op een JSF pagina ineens een stuk scriptlet ga zetten is minimaal. Het -kan- wel, maar het platform ontmoedigd me het; ik kan er weinig mee en het werkt niet lekker samen met de componenten op mijn page.

De enige vereiste is dat de programmeur weet waarmee hij bezig is.

Dit klinkt heel mooi en in een ideale wereld zou dit werken. Maar ik heb -te- vaak meegemaakt dat collega's of stagiares op PHP projecten toch niet helemaal wisten waar ze mee bezig waren. Als er dan bugs ontstaan en de collega is er niet (of erger is vertrokken; geldt nog meer voor stagiares) dan mocht IK de boel fixen Vooral in de grotere projecten kan en mag je gewoon niet iedereen blind vertrouwen op z'n goede inzicht. Je wilt gewoon dat het platform bepaalde dingen afdwingt. Vandaar ook dat ik stelde dat voor vooral grotere projecten PHP eigenlijk niet de aangewezen keuze is.

Nu doen we vooral Java projecten en af een toe ASP.NET en de strakheid die deze platformen bieden zijn gewoon veel groter. Merk op dat voor de ouderwetse JSP + scriptlet pagina's hetzelfde geldt als voor PHP. Gelukkig kun je in Java het gebruik van scriptlets in pagina's eenvoudig globaal verbieden en dus het gebruik van enkel JSTL en/of JSF afdwingen.

[Verwijderd]

flowerp schreef op zondag 21 mei 2006 @ 01:04:[...]
Al deze 'dwang' mis je in PHP. [...]

code:

<jsp:include page="scripts/login.jsp" />
<jsp:include page="scripts/database.jsp" />
<jsp:include page="scripts/businesslogic.jsp" />
<%
//hacking and slashing 
%>

Ik merk ook vrij weinig van die vermeende dwang in jsp hoor

[flowerp]

Verwijderd schreef op zondag 21 mei 2006 @ 13:14:
[...]

code:

<jsp:include page="scripts/login.jsp" />
<jsp:include page="scripts/database.jsp" />
<jsp:include page="scripts/businesslogic.jsp" />
<%
//hacking and slashing 
%>

Ik merk ook vrij weinig van die vermeende dwang in jsp hoor

Hahaha.... scherp Mark Idd, kun je op die manier net zo ranzig bezig zijn als in PHP. Maar ik heb het toch geloof ik al eerder gezegd dat plain old JSP feitelijk identiek is aan PHP.

Daarom maar even mezelf quoten:

Gelukkig kun je in Java het gebruik van scriptlets in pagina's eenvoudig globaal verbieden en dus het gebruik van enkel JSTL en/of JSF afdwingen.

Een verder verschil tussen ranzig bezig zijn in JSP (wat dus technisch kan), is dat het in de hele Java community bekend is dat je dit niet moet doen, terwijl het in PHP gewoon de norm is en blijft. Kijk alleen maar eens naar de postings hier. Elke Java beginner maakt dezelfde fout door logica op JSP's te gaan zetten, en in 99% van de gevallen reageert de hele Java gemeenschap hier meteen door te zeggen dat deze beginner het niet zo moet doen.

Vergelijk dat met PHP posts en PHP beginners. PHP beginners maken dezelfde fouten als Java beginners, alleen de PHP community hier moedigd deze beginners juist aan in dit gedrag en gaat voorbeelden zitten te geven waar ze maar business logic op pages blijven duwen.

-dat- is toch een enorm verschil niet?

Tevens onderstreept dit het belang dat in de nieuwe Java EE 5 revisie JSF de standaard view technology wordt. Niet dat JSF ansich nu het beste van het beste is en dat het concept niet al jaren bestond, maar het simpele feit dat dit de standaard en default voor Java wordt zal heel veel beginners uit de standaard valkuil van 'logic in pages' helpen.

[NMe]

flowerp schreef op zondag 21 mei 2006 @ 13:38:
Een verder verschil tussen ranzig bezig zijn in JSP (wat dus technisch kan), is dat het in de hele Java community bekend is dat je dit niet moet doen, terwijl het in PHP gewoon de norm is en blijft. Kijk alleen maar eens naar de postings hier. Elke Java beginner maakt dezelfde fout door logica op JSP's te gaan zetten, en in 99% van de gevallen reageert de hele Java gemeenschap hier meteen door te zeggen dat deze beginner het niet zo moet doen.

Maar schrijf je daarom maar meteen de taal af? Jouw oorspronkelijke stelling was dat PHP ongeschikt was voor een professionele grote site als Tweakers.net. Wat boeit dan de rest van de community? Er is maar een handvol programmeurs relevant voor het bedrijf in kwestie, en dat zijn de programmeurs die daadwerkelijk aan de site werken. Wat jij zegt komt erop neer dat Jan en Piet geen PHP mogen gebruiken omdat Frits en Sjaak geen idee hebben waar ze mee bezig zijn. Beetje krom, niet?

[Rainmaker]

Ik heb ooit op een stage gebruik gemaakt van een programmeertaal "webdev". Kun je gewoon in een IDE redelijk uitgebreide webapplicaties schrijven. Dit kan werken als een .exe die je vanaf de server draait. Die executable geeft dan HTML terug. Dit kan ook ala AJAX, dus "realtime". Of het echt geschikt is voor een chatapplicatie, durf ik niet te zeggen.

Een voorbeeld zie je bijvoorbeeld op www.philips-lighting.nl

[flowerp]

-NMe- schreef op zondag 21 mei 2006 @ 14:05:
[...]
Beetje krom, niet?

Laten we er maar geen wellis/niettis spelletje van maken Natuurlijk is het niet zo zwart/wit als ik mischien hierboven liet voorkomen. Als tweakers of de mensen van React profesionele developpers hebben zitten die goed uit de voeten kunnen met PHP, des te beter voor hun.

Wat ik alleen poogde te doen, is een reply te geven op wat niet zo sterk onderbouwde opmerkingen in deze thread dat PHP minder geschikt is voor profesioneel gebruik. Ik noemde daarbij een aantal ellementen op die PHP mist (sommige wat duidelijker als andere) en die in het algemeen gewaardeerd worden door mensen die developpen als hun dagelijkse werk hebben maar minder gewaardeerd worden door hobbyisten die incidenteel wat scripten.

Mischien is het ook aardig om de omgekeerde situatie eens te bekijken. We hebben nu een aantal dingen gezien die PHP mist t.o.v. bv Java, ASP.NET of eventueel ROR. Welke elementen die gewaardeerd worden in een profesionele omgeving heeft PHP wel die je bijvoorbeeld mist andere omgevingen?

Het enige voordeel dat ik zo kan bedenken is het feit dat er overal PHP hosting voor een appel en een ei te koop is. Dit is gewoon een sterk voordeel, maar ook weer een voordeel die sterk spreek voor hobbyisten en wat minder of helemaal niet voor bedrijven die hun eigen dedicated server(s) nodig hebben.

[seamus21]

Ok. Ik heb dit topic nu helemaal doorgelezen. Op de eerste pagina waren de reacties nog een beetje gericht op hulp. Echter daarna dwaalde het af en proefde ik dat het vooral ging om 'je gelijk halen' en voegde het weinig toe aan het helpen beantwoorden van de TS.

Het is gewoon zo simpel als.

Welke functionaliteit wil ik?
Waarmee gaan we dat maken?

Als je deze stappen weer verder opdeelt kom je vanzelf zaken tegen die wel of niet kunnen met een bepaalde oplossing. Je hebt niet altijd de keuzevrijheid om alles het 'beste' van te kiezen. Soms moet je concessies doen zelfs in de taal.

Voorbeeld van reacties:

Mithrandir schreef op vrijdag 19 mei 2006 @ 12:33:
[...]Zoals al veel eerder en vaker hier is gezegd: Je hebt een PUSH protocol nodig, geen PULL protocol. PHP kán geen push geven naar de client, dus je bent veel beter af met java.

Erkens schreef op vrijdag 19 mei 2006 @ 12:37:
[...]bullshit, je kan prima pushen via een http verbinding die je open laat staan, wat met PHP erg eenvoudig te implementeren is.

-NMe- schreef op vrijdag 19 mei 2006 @ 12:38:
[...]Ja, en je kan ook prima dikke stront door een trechter duwen. Het protocol is er gewoon niet op gemaakt, punt.

-NMe- schreef op vrijdag 19 mei 2006 @ 12:57:
[...]
Soms is bij lange na niet altijd.
[...]Onze manier van reageren? Je bedoelt het gebruiken van argumenten om aan te tonen dat jouw argumenten simpelweg niet kloppen?

Ik vind dat iedereen maar vooral modjes iets zorgvuldiger hun argumenten of woorden moeten kiezen. Eerst zeggen dat iets niet kan en vervolgens een ander argument geven om iemand anders zijn 'ongelijk' aan te tonen slaat natuurlijk nergens op. Niet kunnen en iets gebruiken waar het misschien niet voor bedoeld is is niet hetzelfde. Punt.

chuxiej schreef op donderdag 04 mei 2006 @ 23:40:
Voor een toekomstig project hebben wij een chat applicatie nodig.
Nu twijfelen wij heel erg aan de mogelijkheden die er zijn om dit waar te maken.
Wij hebben 2 mogelijkheden en zouden advies van personen met ervaring hiermee erg op prijs stellen.
Onze voorkeur gaat echt uit naar de PHP/Javascript manier aangezien wij deze zelf kunnen programmeren en uitbreiden.

De vragen zijn:
1. Kan een PHP/Javascript based client een hoog bezoekers aantal (meer dan 1000 chatters op het zelfde moment) aan zonder delay/lag?
2. Zitten er grote nadelen aan het maken van de client in PHP/Javascript?
3. Kan iemand een hele ruwe indicatie geven hoeveel wij kwijt zullen zijn voor een chatbox met de onderstaande functionaliteiten?
4. Kan iemand een hele ruwe indicatie geven hoeveel wij kwijt zullen zijn voor java webcam applicatie?

Functionaliteiten chatbox:
- Meerdere kanalen
- Prive chats
- Webcam mogelijkheden in prive chats (java)
- Profiel kunnen bekijken

Server:
PHP-CGI programma welke op de server blijft draaien

Client:
- PHP / Javascript based, in een iframe blijft een php script zonder execution_time/timelimit draaien welke javascript commando's verstuurd naar main chatwindow
- Java based client


PHP client
Voordelen
- Makkelijk zelf aan te passen en nieuwe functies toe te voegen
- Lagere productie kosten

Java client
Voordelen
- Meer real time

Nadelen
- Moeilijk dingen zelf aan te passen
- Hoge productie kosten

Bedankt voor de hulp!

1. Kan een PHP/Javascript based client een hoog bezoekers aantal (meer dan 1000 chatters op het zelfde moment) aan zonder delay/lag?

Niet zonder lag

2. Zitten er grote nadelen aan het maken van de client in PHP/Javascript?

Ja vooral in de communicatiehoek.

3. Kan iemand een hele ruwe indicatie geven hoeveel wij kwijt zullen zijn voor een chatbox met de onderstaande functionaliteiten?

Tjeempie... in deze vraag zitten ongeveer 100 hidden vars verwerkt waar rekening gehouden mee dient te worden. Als dit een hobby chat client / server is 1 maand. Moet dit commercieel ingezet worden dan schat ik 1-5 maanden.

4. Kan iemand een hele ruwe indicatie geven hoeveel wij kwijt zullen zijn voor java webcam applicatie?

Zelfde verhaal. 1- 5 maanden.

Je maakt voor de PHP client wel wat aannames waar ik het niet mee eens ben. Productiekosten zijn waarschijnlijk wel lager maar je onderhoudskosten zullen waarschijnlijk hoger liggen dan als je dit oplost met een taal die zich meer leent voor client / server webapps.

Andersom geld dus voor de java client dat misschien de productiekosten hoger zijn maar je krijgt hier een lager onderhoudsplaatje voor terug.

Als ik dit zou moeten maken dan zou ik kiezen voor een Java oplossing die hier al is aangedragen nl Struts. Waarom?

- Deze structuur leent zich perfect voor grotere webapplicaties.
- Een hoop code is transparant
- Minder onderhoud door de MVC structuur

Nadelen:

- Zoals je al aangaf kun je dit niet zelf?
- Je moet een applicatieserver op je host kunnen draaien.

[Verwijderd]

seamus21 schreef op zondag 21 mei 2006 @ 15:36:
Als ik dit zou moeten maken dan zou ik kiezen voor een J2EE oplossing die hier al is aangedragen nl Enterprise Java Beans. Waarom?

- Deze structuur leent zich perfect voor grotere webapplicaties.
- Een hoop code is transparant
- Minder onderhoud door de MVC structuur

Nadelen:
- Zoals je al aangaf kun je dit niet zelf?
- Je moet een applicatieserver op je host kunnen draaien.

EJB heeft op zichzelf vrij weinig met MVC van doen en om het rijtje van nadelen maar even aan te vullen:
- Deze structuur leent zich niet grotere webapplicaties, het is log en bloated.
- Code is niet transparant, want het wordt vervuild door IoC - Dependency Lookup
- Ontwikkelen is duur door de overhead aan code die nodig is.

En zo zijn en er nog wel een hoop valide argumenten te verzinnen om juist niet voor EJB te kiezen. De vele alternatieven op EJB (binnen de java webwereld) geven dat wel aan.

[seamus21]

Verwijderd schreef op zondag 21 mei 2006 @ 15:51:
[...]

EJB heeft op zichzelf vrij weinig met MVC van doen en om het rijtje van nadelen maar even aan te vullen:
- Deze structuur leent zich niet grotere webapplicaties, het is log en bloated.
- Code is niet transparant, want het wordt vervuild door IoC - Dependency Lookup
- Ontwikkelen is duur door de overhead aan code die nodig is.

En zo zijn en er nog wel een hoop valide argumenten te verzinnen om juist niet voor EJB te kiezen. De vele alternatieven op EJB (binnen de java webwereld) geven dat wel aan.

Zei ik EJB's ik bedoelde eigenlijk Struts

[flowerp]

seamus21 schreef op zondag 21 mei 2006 @ 16:02:
[...]
Zei ik EJB's ik bedoelde eigenlijk Struts

Struts was leuk, maar is opgevolgd door JSF. Eigenlijk kies je alleen nog voor Struts als je een legacy app hebt daarin die je moet uitbreiden.

Vervolgens geldt voor JSF (en ook Struts) mbt chatten hetzelfde verhaal, het is gebasseerd op HTTP en pull's. Nu is dat voor JSF mischien theoretisch niet zo (het is in de kern technology onafhankelijk), maar als je zelf je eigen JSF componenten wilt schrijven voor het IRC of gelijkwaardig protocol dan lijkt me dat niet helemaal de juiste weg om te beginnen.

Wat je voor chatten wilt is gewoon een long running server-side service die continue draait. Deze service is in essentie weinig meer dan 1 of meerdere threads die luisteren naar inkomende communicatie op een bepaalde poort en dat (na controlle) door relayen naar 1 of meerdere geregistreerde geregistreerde partijen.

Zoals al vaker gezegd hier, voor de client site komen eigenlijk alleen Java applets en Flash in aanmerking als het op een website moet draaien. De penetratie van de Flash plug-in is groter, maar die voor Java is ook zeker niet klein en net zoals de Flash plug-in heb je hem zo gedownload. Vroeger was het downloaden van een plug-in nog een groot obstakel, maar tegenwoordig heeft 90% van de mensen ADSL of kabel. Of er nu 7 of 14 MB gedownload moet worden merk je amper meer. Als het de bedoeling is dat het standalone moet draaien dan ben je eigenlijk GAIM oid aan het nabouwen. Als ik TS goed begrijp is zoiets niet de bedoeling.