PHP-plugin v0.9b

[Verwijderd]

Sign van DRM drm

code:

PHP-plugin v0.9b - PHP tiplist
willem169: Een oud en wijs man zei ooit 'Lees de draad voor je blaat

Wat is die PHP-plugin? Waar kan ik er meer informatie over vinden en hoe bevalt het?

drm

[ Voor 0% gewijzigd door drm op 10-11-2002 14:07 . Reden: schrijf tenminste m'n naam goed :( ]

[Verwijderd]

Daar loop ik de laatste dagen ook al mee in mijn hoofd. Ik kan er weinig over vinden, maar ik heb het idee dat de plugin het onder andere mogelijk maakt data uit te wisselen zonder pagina's steeds opnieuw op te bouwen.

[SH007]

[rml][ PHP-Plugin] Wat is het?[/rml]

[Verwijderd]

Verwijderd schreef op 09 november 2002 @ 21:30:
Daar loop ik de laatste dagen ook al mee in mijn hoofd. Ik kan er weinig over vinden, maar ik heb het idee dat de plugin het onder andere mogelijk maakt data uit te wisselen zonder pagina's steeds opnieuw op te bouwen.

is 1 of andere geintje wat een stel lui @ irc hebben verzonnen.. tis allemaal fake.. geloof me maar..


--

die dingen die ze steeds zeggen.. alles wat je vraagd @ irc / devschuur krijg je .. ja da kan met de PHP plugin. . werd er helemaal gek van .. die plugin kan zeker niemand installeren.. als je hem installt zegt ie dat je IE versie niet goed is zeker ?? dacht ik al . .fakers... pff

[wasigh]

Verwijderd schreef op 09 November 2002 @ 21:32:
[...]

is 1 of andere geintje wat een stel lui @ irc hebben verzonnen.. tis allemaal fake.. geloof me maar..


--

die dingen die ze steeds zeggen.. alles wat je vraagd @ irc / devschuur krijg je .. ja da kan met de PHP plugin. . werd er helemaal gek van .. die plugin kan zeker niemand installeren.. als je hem installt zegt ie dat je IE versie niet goed is zeker ?? dacht ik al . .fakers... pff

Wel apart iig, dat een serverside techniek af blijk te hangen van een Programma op de client

[ACM]

De mozilla versie doet het anders prima:

[SWINX]

ACM: Maar wat doet de plugin dan?

[ACM]

.php parsen natuurlijk.

[SWINX]

mjah... maar nu weet ik nog niks...

is het voor gebruik op de client zodat je geen apache ofzo nodig hebt???

zo nee, wat is dan het nut van dat plugin ding...


Ik las in het andere draadje waar SH007 naar toe linkt ook iets over client -> server maar daar werd ik ook al niet wijzer van.

Is er anders misschien een website over?

[Verwijderd]

tis fake.. dat van ACM is of een soep .. of gewoon een fake plugin geinstalleerd.. die link met de plugin.exe das gewoon ff in delphi wat geprogt.. en nog iemand van irc gaf een keer een screenshot.. had ie Editplus veranderd in Licensed to PHP PLUGIN bla bla.. dikke fake dus... laat ze maar.. mietjes..

[wasigh]

Ik ken ACM niet als iemand die onzin verteld,
misschien hebben een wrapper om de PHP-parser geschreven zodat hij dienst kan doen als
mozilla plugin?

[Verwijderd]

want het was zo dat ALLES met de php plugin kon.. alle dingen met javascript, menutjes, rechtermuisknop menutjes, eregreplacen via javascrip-t / php ,.. echt alles wat je niet wist kon er mee.. maar als je iemand vroeg hoe het werkte.. uhmm jah dat moet je zelf maar uit zoeken of zoek een compiler en parse het .. bla bla .. volgens hun kon je van VISUALBASIC files die files omzetten in PHP CLASS FILES!! hahaha.. grapjassen!!

pff..

[wasigh]

mm, het is wel mogelijk om met Javascript plugins van Netscape/mozilla aan te roepen. Dus zo gek klinkt het niet

[Verwijderd]

maar blijf er nog steeds nix van geloven

[Verwijderd]

Trouwens, die GTK van PHP is wel rete-leip!

[kvdveer]

Ik ben er zelf goed over te spreken... Die download trouwens niet: die is gecompileerd voor een of andere zeldzame betaversie van IE volgens mij. Fresh CVS is natuurlijk het beste, zeker voor zo'n plugin die zo hard ontwikkeld wordt.

Zoals Stoel al zei: bijna alles kan er mee. Doordat de PHP-plugin de bariere tussen serverside en clientside opheft zijn er een hoop zaken die ineens wel kunnen. Daarnaast is er een geweldige object-library, waar onderandere goedwerkende menu's, mouse-overs en zo in zitten. In javascript was een object-library ondenkbaar, maar met de PHP-plugin werkt het erg goed.

Dat forumobject wat genoemd werd is trouwens niet helemaal flex. Doordat de cookies clientside en serverside worden opgeslagen (wie heeft dat verzonnen? ) ben je je login kwijt als je IP verandert... nogal kut voor modemgebruikers. Ook het usersysteem is nog niet helemaal in orde. Maar wat wil je? het is beta-software!

[kvdveer]

Verwijderd schreef op 10 november 2002 @ 13:48:
Trouwens, die GTK van PHP is wel rete-leip!

Het nog wel wat buggy... Probeer maar GTK-objecten naar elkaar te laten referencen... Dan hangt je machine gelijk... ik heb al zitten werken aan een patch, maar dat wil niet erg...

PHP:

// Edit: Niet vergeten je includes te doen!!!
include("GTK/main.php")

// objectfactory aanmaken
$env = new GTK();

// ik maak voor de lol maar even volledige windows aan
// widgets zouden natuurlijk ook kunnen.
$win1 = $env->getNewBaseWindow("windoowtje 1");
$win2 = $env->getNewBaseWindow("Nog een window");

// parent instellen...
$win1->setParent($win2);
// en hierop hangt 'ie dus...
$win2->setParent($win1);

[Mithrandir]

Wanneer komt die nieuwe (v1.0a) nou?

[drm]

't is ook niet voor niks een beta, he, kvdveer

[wasigh]

[Verwijderd]

Al mocht dit alles waar zijn, er is nog steeds geen (imho) goed antwoord gegeven op de vraag van de topicstarter, wat is dit voor plugin, wat kan je er mee? waar is het te vinden?

ik heb zelf net ff rustig meerdere topics gelezen over deze 'plugin' en moet zeggen dat er meer omheen gel*ld word dan dat er iets nuttigs over dit scriptje/plugin/stukje software wordt vermeld..

Komop ppl, post eens wat nuttigs zodat ik het ook kan lezen en begrijpen...

1. url van de website? (handig)
2. een verhaaltje wat je er daadwerkelijk mee kan

etc

[Verwijderd]

offtopic:
wist niet dat modjes een post mochten editen ivm een 'verkeerd' geschreven username

^{extra post omdat ik niet wil inloggen op 'dit' systeem.}

[whoami]

Verwijderd schreef op 10 november 2002 @ 14:53:

offtopic:
wist niet dat modjes een post mochten editen ivm een 'verkeerd' geschreven username

^{extra post omdat ik niet wil inloggen op 'dit' systeem.}

Tja, ik zie niet echt in waarom jij daar een probleem over maakt. Het bericht is bewijzigd, maar het is wel nog altijd duidelijk wat de oorspronkelijke post was.

En nu verder on-topic.

[TheRebell]

het enige wat ik zo snel zie is de link naar de plugin zelf
http://www.xs4all.nl/~oisyn/files/phpplugin0.9b.exe

wat je ermee kunt......:? geen id

[ACM]

Verwijderd schreef op 10 november 2002 @ 14:51:
2. een verhaaltje wat je er daadwerkelijk mee kan

Clientside php.
Je weet toch wat php kan
Dan weet je toch ook wat je ermee kan als het client-side draait??

[kvdveer]

TheRebell schreef op 10 november 2002 @ 15:00:
het enige wat ik zo snel zie is de link naar de plugin zelf
http://www.xs4all.nl/~oisyn/files/phpplugin0.9b.exe

wat je ermee kunt......:? geen id

Wat je er mee kunt... zie hierboven. Omdat de CVS draait op iemand z'n kabelaansluiting hebben ze liever niet dat daar linkjes naartoe worden gepost...

[TheRebell]

oke, sorry kvdveer

maar nee, het is nou niet echt duidelijk wat je ermee kunt. Oke, je kan dan dus je PHP scripts parsen op de pc van een client maar dan moet je dus ook je code meesturen/zenden/whatever
Zie het nut nog niet zo in eigenlijk, oke je hebt iets minder traffic naar je server maar of dat nou zoveel uitmaakt....

[wasigh]

Zoals ik het begrepen heb is het mede ontwikkeld door kvdveer en DRM ( )
Net zat ik te denken dat het client side parsen van PHP redelijk wat veiligheids risico's met zich mee brengt. Ik vraag me af hoe jullie dit opgelost hebben.

Ten tweede vraag ik me af van welke functionaliteit in de nieuwste (gelekte) IE beta de plugin af zou kunnen hangen? In de changelog daarvan kan ik namelijks niets vinden wat verband kan houden met plugin.
Tevens zijn er geen grote wijzigingen in de plugin infrastructuur aangekondigd.

Ten derde zeggen jullie dat de plugin in zeer sterke ontwikkeling is. Wat zijn de features die jullie voor de release gepland hebben? Wat voldeed er niet aan de vorige versies? Waar kunnen we de ontwerpdocumenten inzien?

[Verwijderd]

Verwijderd schreef op 09 November 2002 @ 22:51:
tis fake.. dat van ACM is of een soep .. of gewoon een fake plugin geinstalleerd.. die link met de plugin.exe das gewoon ff in delphi wat geprogt..

ohhh vandaar dat er "Microsoft Visual C++ Runtime Library" in staat!

[wasigh]

kvdveer schreef op 10 November 2002 @ 15:04:
[...]

Wat je er mee kunt... zie hierboven. Omdat de CVS draait op iemand z'n kabelaansluiting hebben ze liever niet dat daar linkjes naartoe worden gepost...

Als dat het probleem is:
Ik heb nog wel een CVS server met een mooie 100mbit verbinding, volledig tot jullie beschikking. Dus dat kunnen we regelen

[Bosmonster]

Precies.. Als je VBSCript en Javascript zat bent.. ben je toch blij dat je je DHTML en clientside databinding enzo in PHP kan doen?

[wasigh]

Bosmonster schreef op 10 november 2002 @ 15:18:
Precies.. Als je VBSCript en Javascript zat bent.. ben je toch blij dat je je DHTML en clientside databinding enzo in PHP kan doen?

Client-side databinding? Wat bedoel je daarmee? Dat de database gekopieerd wordt naar de gebruiker. Dat er via de PHP parser verbinding wordt gelegd met een remote Database?

In beide gevallen mijn vraag: hoe wordt dat beveiligd. Hoe zorg je voor een platformonafhankelijke data overdracht. Hoe verloopt de plugin detectie. Hoe zorg je dat mensen de de plugin niet hebben toch een mooie pagina voor hun neus hebben?

[drm]

xtentic:

offtopic:
wist niet dat modjes een post mochten editen ivm een 'verkeerd' geschreven username

offtopic:
Ik ben geen modje
En 't was ook meer een geintje dan dat ik elke post ga zitten editten waar mijn nickname verkeerd in staat. En da's ook echt het enige wat ik aan de post veranderd heb.

[wasigh]

drm schreef op 10 november 2002 @ 15:28:

[...]

offtopic:
Ik ben geen modje
En 't was ook meer een geintje dan dat ik elke post ga zitten editten waar mijn nickname verkeerd in staat. En da's ook echt het enige wat ik aan de post veranderd heb.

Als je dan toch reageerd reageer dan inhoudelijk

[Verwijderd]

ACM schreef op 10 november 2002 @ 15:04:

[...]

Clientside php.
Je weet toch wat php kan
Dan weet je toch ook wat je ermee kan als het client-side draait??

ik weet wat php is, maar waarom client side? dat vat ik niet, mja zal veel meer mogelijkheden bieden!...maar wat bied het dan?

TheRebell schreef op 10 november 2002 @ 15:08:
oke, sorry kvdveer

maar nee, het is nou niet echt duidelijk wat je ermee kunt. Oke, je kan dan dus je PHP scripts parsen op de pc van een client maar dan moet je dus ook je code meesturen/zenden/whatever
Zie het nut nog niet zo in eigenlijk, oke je hebt iets minder traffic naar je server maar of dat nou zoveel uitmaakt....

Ben ik het niet mee eens, ik heb wel eens een scriptje gehad die veel groter was dan de 'output' zie mijn sig

drm schreef op 10 november 2002 @ 15:28:

[...]

offtopic:
Ik ben geen modje
En 't was ook meer een geintje dan dat ik elke post ga zitten editten waar mijn nickname verkeerd in staat. En da's ook echt het enige wat ik aan de post veranderd heb.

Ok anders

wasigh schreef op 10 November 2002 @ 15:29:
[...]

Als je dan toch reageerd reageer dan inhoudelijk

Mwah dat doet ie ook wel, beetje

[drm]

Ok, het probleem met de code van de php-plugin is, dat hij nog dermate slecht in elkaar zit, en om het een beetje levens-kans te geven, is er besloten om deze niet vrij te geven, voordat er allerlei commentaar op komt waar we niet op zitten te wachten. Basically moeten we dus een cleane versie maken, en dan gaan we dan besluiten of het uberhaupt open-source gaat. Waarschijnlijk dus niet.

Verder is de documentatie nog lang niet uitgewerkt, (wie begint er nou met de documentatie? ) en kan daar ook nog niets over verteld worden. Je zou het gewoon uit moeten proberen. En als je de Mozilla versie van de plugin wilt, zul je even met ACM moeten babbelen, die heeft de IE versie omgebouwd.

Verder hopen we dat we over een paar jaar het kaliber bereikt hebben van een plugin als Flash.

Wat je ermee kan?
Denk aan hele eenvoudige dingen. Heel veel van de code die op het internet zit is niet hergebruikt, en daarom wordt de PHP -plugin langzamerhand een fenomeen waarin de meest triviale zooi al in zit opgebouwd. Hoeveel forumpjes hebben mensen al niet gebouwd? Waarom alles opnieuw doen?

PHP:

$forum = new Forum ( "Gathering of Tweakers" );
$groups = $forum->getForumsByGroup ();
$i = $groups->iterator ();
while ( $i->hasNext () ) {
   // hier de zut die je forum overzicht maakt;
   $i->next ();
}

Dat soort dingen dus. Of:

PHP:

$site = new Site ();
$site->setInterface ( Templates [ 'maintemplate' ] );

etcetera. Het maakt het leven van de devver gewoon een stuk makkelijker, en op den duur hopelijk ook van de site-gebruiker, omdat de load geminimaliseerd wordt (alles wordt optimized).

[wasigh]

drm schreef op 10 november 2002 @ 16:36:
Ok, het probleem met de code van de php-plugin is, dat hij nog dermate slecht in elkaar zit, en om het een beetje levens-kans te geven, is er besloten om deze niet vrij te geven, voordat er allerlei commentaar op komt waar we niet op zitten te wachten. Basically moeten we dus een cleane versie maken, en dan gaan we dan besluiten of het uberhaupt open-source gaat. Waarschijnlijk dus niet.

Dermate slecht dat het een versie 0.9 Beta is. Vrij apart versie beheer hebben jullie dan. Heb je dan misschien een. Dat je hem niet vrijgeeft kan ik opzicht inkomen. Maar wat zijn de de belangrijkste features? Wat zijn de prognoses wanneer kan men de final verise verwachtten? Waarom werkt hij alleen met een IE beta? die vragen heb je nog niet beantwoord. Waarom was eerst de CVS het probleem en nu ineens de slechte code? welke mensen ontwikkelen eraan?

(en waarom kunnen zij niet coden )

Verder is de documentatie nog lang niet uitgewerkt, (wie begint er nou met de documentatie? ) en kan daar ook nog niets over verteld worden. Je zou het gewoon uit moeten proberen. En als je de Mozilla versie van de plugin wilt, zul je even met ACM moeten babbelen, die heeft de IE versie omgebouwd.

Dus jullie ontwikkelen in een team (waarom anders CVS? ) en jullie hebben geen overleg gehad over de manier van ontwikkelen? De functionaleit die erin moet? En de eisen mbt tot veiligheid? Jullie hebben op geen enkele manier gecommuniceerd en jullie weten toch wat jullie moeten maken. Dat is knap! En zeker een aparte manier van werken!

Verder hopen we dat we over een paar jaar het kaliber bereikt hebben van een plugin als Flash.

Paar jaar? Dus jullie hebben wel een idee wanneer het af moet zijn, maar jullie hebben niet overlegd wat erin moet komen. Helemaal super Tevens zijn jullie nu bij versie 0.9 en over een paar jaar bij 1.0 Dat jullie apart werken waren we al achter

Wat je ermee kan?
Denk aan hele eenvoudige dingen. Heel veel van de code die op het internet zit is niet hergebruikt, en daarom wordt de PHP -plugin langzamerhand een fenomeen waarin de meest triviale zooi al in zit opgebouwd. Hoeveel forumpjes hebben mensen al niet gebouwd? Waarom alles opnieuw doen?

PHP:

$forum = new Forum ( "Gathering of Tweakers" );
$groups = $forum->getForumsByGroup ();
$i = $groups->iterator ();
while ( $i->hasNext () ) {
   // hier de zut die je forum overzicht maakt;
   $i->next ();
}

Dat soort dingen dus. Of:

PHP:

$site = new Site ();
$site->setInterface ( Templates [ 'maintemplate' ] );

etcetera. Het maakt het leven van de devver gewoon een stuk makkelijker, en op den duur hopelijk ook van de site-gebruiker, omdat de load geminimaliseerd wordt (alles wordt optimized).

Leuk algemeen verhaaltje over OO, wat nu ook al mogelijk is met PHP
Waarom pakken jullie een serverside techniek om er een client-side techniek van te maken en zo de voordelen van server-side technieken te niet te doen?
Zoals makkelijke code software updates. Stel je voor dat de parse forum client side zou draaiien en er komt een nieuwe versie, dan moeten alle ruim 30.000 bezoekers van GoT nieuwe software downloaden. Bovendien: hoe groot is dat veiligheidsgat als ik client side de code voor de topicadmin aanpas en zo direct communiceer met de database?

[Verwijderd]

wasigh schreef op 10 november 2002 @ 16:49:
[..]
Leuk algemeen verhaaltje over OO, wat nu ook al mogelijk is met PHP
Waarom pakken jullie een serverside techniek om er een client-side techniek van te maken en zo de voordelen van server-side technieken te niet te doen?
Zoals makkelijke code software updates. Stel je voor dat de parse forum client side zou draaiien en er komt een nieuwe versie, dan moeten alle ruim 30.000 bezoekers van GoT nieuwe software downloaden. Bovendien: hoe groot is dat veiligheidsgat als ik client side de code voor de topicadmin aanpas en zo direct communiceer met de database?

daar zit ik dus echt wel op te wachten, wil wel eens wat lezen van die fora's

[drm]

wasigh Ik ben blij dat jij niet meewerkt want je bent veel te kritisch. Je hebt gelijk op alle fronten, en het is ook een brak ontwikkelteam, maar ja dat krijg je als je dit soort dingen in de hobby-sfeer met andere prutsers van GoT gaat ontwikkelen

[wasigh]

drm schreef op 10 november 2002 @ 16:57:
wasigh Ik ben blij dat jij niet meewerkt want je bent veel te kritisch. Je hebt gelijk op alle fronten, en het is ook een brak ontwikkelteam, maar ja dat krijg je als je dit soort dingen in de hobby-sfeer met andere prutsers van GoT gaat ontwikkelen

Dat ik gelijk heb hoef je me niet te vertellen

Zoals ik al tegen ACM heb verteld vindt ik het een interressante ontwikkeling waar zeker toekomst in zit! Alleen is het dan wel van groot belang dat er naar een aantal belangrijke thema's genoeg aandacht besteed wordt.

Hoe meer jullie er over posten hoe onduidelijker en vager het allemaal wordt, eerst is het de oplossing voor al je problemen en daarna is het te brak om maar te mogen runnen. Ik ben gewoon benieuwd

En als je niet tegen kritiek en meedenken kan, moet je het niet zo opvallend in je sig zetten

[kvdveer]

wasigh schreef op 10 november 2002 @ 15:09:
Zoals ik het begrepen heb is het mede ontwikkeld door kvdveer en DRM ( )
Net zat ik te denken dat het client side parsen van PHP redelijk wat veiligheids risico's met zich mee brengt. Ik vraag me af hoe jullie dit opgelost hebben.

In principe op dezelfde manier als bijvoorbeeld javascript en vbscript: het runt in een gesloten virtual machine. Momenteel zitten er behoorlijk wat lekken in, maar het wordt al langzaam beter. Een van de belangrijkste features is eigenlijk de codebase die er bij de plugin zit. Zoals je ziet is de plugin niet zo groot. De eigenlijke code wordt on demand verzonden. Momenteel is dat alleen beveiligd met een MD5 Hash, maar in de toekomst willen we ook werken met certificaten. Hoewel we momenteel maar een mirror hebben, is een wereldwijd mirror-netwerk voor deze code niet ondenkbaar.

Een aantal zaken zijn niet mogelijk in javascript die wel mogelijk zijn in PHP, waaronder de mogelijkheid om socketverbindingen te maken. Die verbindingen zijn natuurlijk riskant, dus momenteel komt er een security-dialog als je een socketverbinding probeert te maken die vanaf de server niet mogelijk zou zijn (zoals bijvoorbeeld een verbinding naar 10.0.0.1 als de server een publiek ip-adres heeft).

Ten tweede vraag ik me af van welke functionaliteit in de nieuwste (gelekte) IE beta de plugin af zou kunnen hangen? In de changelog daarvan kan ik namelijks niets vinden wat verband kan houden met plugin.
Tevens zijn er geen grote wijzigingen in de plugin infrastructuur aangekondigd.

Vanwege de (bovengenoemde) beveiligingsrisicos proberen we zo min mogelijk ruchtbaarheid aan ons project te geven. drm was zo slim om in #devschuur iets te laten vallen over deze plugin, (dat was jij toch?) dus wat het plotseling op heel GOT bekend. Iemand heeft dus snel een binary gefixt en op die xs4all mirror neergepleurt. De cvs is niet public om een aantal redenen: 1. licentiemixing, de plugin bevat bsd-licenced code en lgpl code... die mix moeten we zien op te lossen voordat we publiek gaan. 2. De cvs draait achter iemands kabelmodem... Chello (toch?) zal vast niet blij zijn als iedereen de cvs ging uitchecken. 3. Er zijn nog een aantal beveiligingslekken 'by design' die moeten worden gedicht... Liefst hebben we geen negatieve publiciteit voordat de eerste final uitkomt.

Om de juridische veiligheid van het project te waarborgen werken we niet met gelekte beta's. We hebben eenmaal gewerkt met een MSDN beta van IE 6, maar nu werken we met de final. De pugin kan in principe gecompileerd worden van alle versies >= 5.5. Zoals gezegd: opera is wat buggy, mozilla gaat al aardig.

Ten derde zeggen jullie dat de plugin in zeer sterke ontwikkeling is. Wat zijn de features die jullie voor de release gepland hebben? Wat voldeed er niet aan de vorige versies? Waar kunnen we de ontwerpdocumenten inzien?

Zoals hierboven al gezegd: We willen gaan werken met certificaten voor de library. Daarnaast willen we transparant-object movement gaan inbouwen. Dit houdt in dat als je een nieuw object aanmaakt het niet perse aan client of serverside hoeft te draaien, op basis van de situatie wordt dit beslist. De server heeft hierin natuurlijk het laatste woord.

wasigh schreef op 10 november 2002 @ 16:49:
Dermate slecht dat het een versie 0.9 Beta is. Vrij apart versie beheer hebben jullie dan. Heb je dan misschien een. Dat je hem niet vrijgeeft kan ik opzicht inkomen. Maar wat zijn de de belangrijkste features? Wat zijn de prognoses wanneer kan men de final verise verwachtten? Waarom werkt hij alleen met een IE beta? die vragen heb je nog niet beantwoord. Waarom was eerst de CVS het probleem en nu ineens de slechte code? welke mensen ontwikkelen eraan?

Toen we begonnen noemden we ons project heel optimistisch v 0.1, toen we de eerste code werkend hadden gingen we al over naar v0.2. In 0.8 liepen we tegen de eerste grote problemen aan (undocumented api's van IE). Toen pas zagen we in dat versie 1 nog heel verweg was.

opmerking
de php-plugin bevat momenteel nog proprietary code. De enige legale versie lijkt dus de downloadbare versie te zijn... Het lijkt er op dat die versie niet echt op veel browsers werkt.. naja jammer dan.
Alle requests naar een gecompileerde versie zijn dus illegaal en in feite een warez-request.

[kvdveer]

Verwijderd schreef op 10 November 2002 @ 16:53:
daar zit ik dus echt wel op te wachten, wil wel eens wat lezen van die fora's

Daarom werken we met md5-signatures en tainted data... Dat moet dus in theorie niet mogelijk zijn.
Een goed ontworpen library-object is hiertegen trouwens beveiligd: directe (read-write) databasetoegang is als het goed is niet mogelijk vanaf de client. Het toegangsbeheer dient dus op de server plaats te vinden.

[Verwijderd]

kvdveer: zoals meerderen al hebben vermeld is denk ik het idee wel vet, maar aan de andere kant is het niet erg nieuw. Leuk is natuurlijk dat de gebruiker zijn machine ingezet wordt voor het opzetten van een pagina dus de 'server' minimaal belast wordt met dit soort dingen maar hoe zit het met de code die verstuurd word. Is deze encoded? valt deze dan niet aftevangen door andere progies en te decoderen?... en at last de server zal nog steeds aardig nodig zijn om de applicatie van de 'rechten' te voorzien.... denk ik.

[drm]

[nohtml]

kvdveer:
Vanwege de (bovengenoemde) beveiligingsrisicos proberen we zo min mogelijk ruchtbaarheid aan ons project te geven. drm was zo slim om in #devschuur iets te laten vallen over deze plugin, (dat was jij toch?) dus wat het plotseling op heel GOT bekend. Iemand heeft dus snel een binary gefixt en op die xs4all mirror neergepleurt.

Ik weet niet meer wie het was, en daar hebben we al discussie over gehad Beetje jammer dat je dat nou weer en plein publique moet roepen

[wasigh]

kvdveer schreef op 10 november 2002 @ 17:10:
[...]

Wel apart dat je dit allemaal weet te vertellen, terwijl drm die ook ontwikkeld dit blijkbaar niet wist. Klinkt interressand iig.

opmerking
de php-plugin bevat momenteel nog proprietary code. De enige legale versie lijkt dus de downloadbare versie te zijn... Het lijkt er op dat die versie niet echt op veel browsers werkt.. naja jammer dan.
Alle requests naar een gecompileerde versie zijn dus illegaal en in feite een warez-request.

Omdat er proprieraty code in een programma zit is de gebruiker illegaal bezig Volgens mij kan de gebruiker dat op geen enkele manier controleren en ligt die verantwoordelijkheid echt bij de programmeur. Om dan dus te spreken van een warez request is pertitent onwaar.


Verder:

Om de juridische veiligheid van het project te waarborgen werken we niet met gelekte beta's. We hebben eenmaal gewerkt met een MSDN beta van IE 6, maar nu werken we met de final. De pugin kan in principe gecompileerd worden van alle versies >= 5.5. Zoals gezegd: opera is wat buggy, mozilla gaat al aardig.

is daarmee volledig in tegenstelling

Hoe hebben jullie er voor gezorgd dat de plugin in al die browsers werkt? Ze hebben allemaal een verschillende plugin structuur.. ik neem aan dat jullie die code zelfgeschreven hebben of ergens gedownload hebben en ik ben er zeker benieuwd naar. Ik hoef niet perse code maar een uitleg lijkt me wel prettig!

Hoe is verder de afhankelijkheid van Javascript? Plugins kunnen naar mijn weten vanuit een webpagina alleen aangesproken worden met Javascript wat als de gebruiker het gebruik van javascript niet toestaat?

edit: en mijn vraag over wie er nu aan werken, en wie er toegang hebben tot de CVS is nog niet beantwoord

[wasigh]

drm schreef op 10 November 2002 @ 17:27:
[nohtml]
[...]

Ik weet niet meer wie het was, en daar hebben we al discussie over gehad Beetje jammer dat je dat nou weer en plein publique moet roepen

Daar hebben ze volgens mij een spreekwoord voor iets met een pot en ketel en zwart

En ik dacht dat jullie niet communiceerden...

[kvdveer]

Verwijderd schreef op 10 November 2002 @ 17:25:
kvdveer: zoals meerderen al hebben vermeld is denk ik het idee wel vet, maar aan de andere kant is het niet erg nieuw. Leuk is natuurlijk dat de gebruiker zijn machine ingezet wordt voor het opzetten van een pagina dus de 'server' minimaal belast wordt met dit soort dingen maar hoe zit het met de code die verstuurd word. Is deze encoded? valt deze dan niet aftevangen door andere progies en te decoderen?...

Dat hangt af van de instellingen van het betreffende object. ER zijn een aantal encryptiemogelijkheden*: base64, md5-protected, gzipped, rijndael, ssl. Ieder van deze mogelijkeheden kan worden ingesteld voor een variabele, samen met een default... Zo'n declaratie ziet er als volgt uit:

PHP:

class forum extends interactive {
  function forum {
    $env = $_CLASS['_enviroment'];
    $env->setTransferProtection(md5 + gzipped + ssl);
    [...]
  }
  [...]
  serverfunction doiets() {
    // als deze function aangeroepen wordt, worden alle variabelen die hier worden 
    // aangeroepen naar de server verhuisd, als ze daar nog niet zijn natuurlijk.
  }
}

en at last de server zal nog steeds aardig nodig zijn om de applicatie van de 'rechten' te voorzien.... denk ik.

Valt mee. Het forumobject dat we nu hebben gebruikt een security-token... Het meeste werk gebeurt client-side, uit het security-token object weet clientside wat er allemaal mag, en wat niet. Er worden dus geen serverfunctions aangeroepen. Pas bij de databasecommit vindt er een serverfunction plaats.
Momenteel zijn trouwens alle mysql_* functie gedefinieerd als serverfunctions...

edit:
* base64 MD5 en gzip zijn geen encryptiemethoden, eerder coderingsmethoden of tainting methoden... maar het idee is duidelijk

[kvdveer]

wasigh schreef op 10 november 2002 @ 17:39:
[...]

Daar hebben ze volgens mij een spreekwoord voor iets met een pot en ketel en zwart

En ik dacht dat jullie niet communiceerden...

Dat heb je als je per mail communiceert - dan vergeet je wel eens iemand... Daar hebben we al vaker last van gehad.

[Verwijderd]

Klikt allemaal erg fijn, wil strax zekers zien wat echt allemaal mogelijk is

[kvdveer]

wasigh schreef op 10 November 2002 @ 17:38:
[...]

Wel apart dat je dit allemaal weet te vertellen, terwijl drm die ook ontwikkeld dit blijkbaar niet wist. Klinkt interressand iig.

drm is meer van de organisatie, ik zit meer in de code.

Omdat er proprieraty code in een programma zit is de gebruiker illegaal bezig Volgens mij kan de gebruiker dat op geen enkele manier controleren en ligt die verantwoordelijkheid echt bij de programmeur. Om dan dus te spreken van een warez request is pertitent onwaar.

zeker niet! Alle beschibare versies (muv die ene waarnaar drm linkt) zijn illegaal, en moeten dus als warezreqeust behandeld worden. HET IS GEEN GPL CODE!

Hoe hebben jullie er voor gezorgd dat de plugin in al die browsers werkt? Ze hebben allemaal een verschillende plugin structuur.. ik neem aan dat jullie die code zelfgeschreven hebben of ergens gedownload hebben en ik ben er zeker benieuwd naar. Ik hoef niet perse code maar een uitleg lijkt me wel prettig!

Er is een algemene api voor plugins... De details verschillen per brower.

Hoe is verder de afhankelijkheid van Javascript? Plugins kunnen naar mijn weten vanuit een webpagina alleen aangesproken worden met Javascript wat als de gebruiker het gebruik van javascript niet toestaat?

Je verwart een aantal zaken... wij maken geen graphical plugin zoals bijvoorbeeld quicktime of flash. Wij maken een zgn functional plugin, die te vergelijken is met de google-toolbar (niet helemaal... de googletoolbar maakt geen gebruik van de plugin-api). Daardoor krijgt php-code eenzelfde status als javascript, met dezelfde restricties: namelijk de door de virtual machine opgelegde restricties, aangezien we zelf de virtual machine schrijven houdt dat in dat we praktisch geen restricties hebben. In tegenstelling tot javascript zijn wìj dus verantwoordelijk voor de veiligheid en niet IE. Je krijgt dan ook een security-dialog als je de plugin installeert in windows, net als je die krijgt bij flash en zo.

[wasigh]

Ik ben even zo vrij geweest om de Code met een HexEditor te bekijken. Ik weet niet welke compiler jullie gebruiken. Maar hij gaat niet echt zuinig om met de bestandsgrootte van de EXE. Misschien dat jullie een betere compiler moeten zoeken

_{Verder mis ik een ref naar winsock.dll}

[marcusk]

LOL Hoe bedenken jullie het

[Verwijderd]

Hmmm .... ik had laatst op de ZEND mailing list iets gelezen over die PHP-plugin .... was een beetje wantrouwend, ik geloof dat ze zelf een concurrent ofzo willen uitbrengen. Ik zal even kijken of ik dat linkje nog kan vinden ...

edit:

Vaag .... 't bericht lijkt verwijderd te zijn. Misschien iets wat ze nog niet naar buiten willen brengen.

[kvdveer]

Verwijderd schreef op 10 november 2002 @ 18:27:
Hmmm .... ik had laatst op de ZEND mailing list iets gelezen over die PHP-plugin .... was een beetje wantrouwend, ik geloof dat ze zelf een concurrent ofzo willen uitbrengen. Ik zal even kijken of ik dat linkje nog kan vinden ...

edit:
Vaag .... 't bericht lijkt verwijderd te zijn. Misschien iets wat ze nog niet naar buiten willen brengen.

Ik heb er nog niet van gehoord... Geef even een gilletje als je er wat over vindt... Uiteraard is ons dev-'team' zeer geinterresseerd. (let op de aanhalingstekens...)

[wasigh]

kvdveer schreef op 10 November 2002 @ 19:00:
[...]


Ik heb er nog niet van gehoord... Geef even een gilletje als je er wat over vindt... Uiteraard is ons dev-'team' zeer geinterresseerd. (let op de aanhalingstekens...)

Hoe vaak moet ik nog vragen naar de lijst van devvers van jullie 'team'?

[kvdveer]

wasigh schreef op 10 november 2002 @ 19:01:
Hoe vaak moet ik nog vragen naar de lijst van devvers van jullie 'team'?

drm, kvdveer, hyperion (!GOT), st1 (!GOT) en nog een paar testers.

[Mithrandir]

Is v1.0a al te krijgen? Die is natuurlijk alpha, maar mag ik testen? Please?

[Verwijderd]

Verwijderd schreef op 10 november 2002 @ 18:27:
Hmmm .... ik had laatst op de ZEND mailing list iets gelezen over die PHP-plugin .... was een beetje wantrouwend, ik geloof dat ze zelf een concurrent ofzo willen uitbrengen. Ik zal even kijken of ik dat linkje nog kan vinden ...

edit:
Vaag .... 't bericht lijkt verwijderd te zijn. Misschien iets wat ze nog niet naar buiten willen brengen.

ik snap ook niet dat dit idee niet veel eerder uitgewerkt is door Zend... Dingen die bijvoorbeeld genoemd werden, zoals serversided DHTML en een aantal enorme objecten waaronder zelfs een forum vind ik een geweldige doorbraak

Deze plugin gaat het helemaal maken, dat weet ik zeker

[kvdveer]

Verwijderd schreef op 10 November 2002 @ 19:07:
Deze plugin gaat het helemaal maken, dat weet ik zeker

Inderdaad! Die RTFM plugin trouwens ook!

[Verwijderd]

kvdveer schreef op 10 November 2002 @ 19:10:
[...]

Inderdaad! Die RTFM plugin trouwens ook!

offtopic:
whehehe.. hij moet nog wat verder gedistibueerd worden hier op GoT geloof ik

[Verwijderd]

ik zou ook wel willen beta testen, zo leer ik weer meer

[Verwijderd]

ahahahha je wilt niet weten hoe hard ik hier zit te lachen.. een zelfdzame BETA van IE ,. yeah right.. haha.. al die php code word steeds verzonnen en wat rare functies er bij gezet.. hahahah.. JULLIE ZIJN ZOOOOOO ONTZETTEND DOM HE!! OMFG>> jullie moesten je schamen

[ACM]

Verwijderd schreef op 10 november 2002 @ 21:57:
ahahahha je wilt niet weten hoe hard ik hier zit te lachen.. een zelfdzame BETA van IE ,. yeah right.. haha.. al die php code word steeds verzonnen en wat rare functies er bij gezet.. hahahah.. JULLIE ZIJN ZOOOOOO ONTZETTEND DOM HE!! OMFG>> jullie moesten je schamen

Zeldzame beta van IE
Een zeldzame beta van een plugin voor IE...

[Verwijderd]

ACM schreef op 10 november 2002 @ 22:19:

[...]

Zeldzame beta van IE
Een zeldzame beta van een plugin voor IE...

ach zo .. naja.. geloof er nog steeds nix van

[Kresh]

Geweldig topic dit
Leuke practical-joke mensen!

Ik neem aan dat polls, gastenboeken, loggers en nieuwssystemen er ook standaard in zitten?

[jelmervos]

Hahahaha, zeer leuk dit. Goede grap!

[Pelle]

kvdveer schreef op 10 november 2002 @ 19:05:
drm, kvdveer, hyperion (!GOT), st1 (!GOT) en nog een paar testers.

* Pelle schopt kvdveer

[Pelle]

Kresh schreef op 10 november 2002 @ 22:42:
Ik neem aan dat polls, gastenboeken, loggers en nieuwssystemen er ook standaard in zitten?

Gastenboeken al wel, polls nog niet.

PHP:

$guestbook = new Guestbook();
$guestbook->loadTemplate("./template/template.html");
$guestbook->loadPostTemplate("./template/post.html");
$guestbook->setNumberOfReactions(20);
$guestbook->output();

Met loadTemplate laad je een template dat een pagina bevat, met loadPostTemplate laad je het template dat wordt gebruikt voor de weergave van 1 reactie.

/edit
Het coole hieraan is bijvoorbeeld dat gebruikers zelf ook een template kunnen gebruiken van hun eigen harddisk:

PHP:

if ($guestbook->personalTemplate($_ENV["PHP_SELF"])) {
    $guestbook->loadPersonalTemplates();
}

Dit is voor de gastenboeken natuurlijk niet echt boeiend, maar voor een forum is het erg handig. Zo kun je iedereen z'n eigen skin laten gebruiken zonder dat daar veel serverside parsing bij komt kijken.

[kvdveer]

Pelle schreef op 10 November 2002 @ 23:24:


* Pelle schopt kvdveer

* kvdveer duikt weg in een donker hoekje... Sorry!!! Pelle codeert ook mee!
Even snel tellen levert zelfs op dat er meer files van jou zijn dan van mij...

[.oisyn]

ja, fijn dat de coder die z'n webspace weggeeft voor die plugin ook niet genoemd wordt

[Sjaaky]

En hoe wordt het onderscheid tussen client- en serverside gemaakt?
Zo?

PHP:

<?php@server
...
?>
<?php@client
..
?>

Just curious

[drm]

Nee, dat wordt voorlopig gedaan door een

code:

<script language="PHPScript">...</script>

waar PHPScript in principe natuurlijk gewoon een woord is wat wij kunnen veranderen in alles wat we willen. Zo geef je de content van je pagina ook duidelijk het onderscheid tussen server en clientsided.... 't Is ook niet de bedoeling dat de PHP-plugin gebruikt wordt voor <?=$var?> achtige constructies.

edit:

trouwens, wasigh, zoals we al zeiden, die executable is heel gauw gemaakt, puur om de ruchtbaarheid een beetje aarde te geven. Er is verder niet nagedacht in deze versie over optimalisatie @compiletime...

[kvdveer]

Sjaaky schreef op 10 november 2002 @ 23:38:
En hoe wordt het onderscheid tussen client- en serverside gemaakt?
Zo?

PHP:

<?php@server
...
?>
<?php@client
..
?>

Just curious

Het echte ondescheid wordt door de code gemaakt.
Sommige functies of objecten zijn clientside only, zoals bijvoorbeeld het window-object van de browser. Andere objecten zijn weer specifiek server-only, zoals de database toegang. De meeste functies (zoals regexp en zo) kunnen aan beide kanten draaien.
Zodra een serverside object of functie wordt aangeroepen worden de relevante objecten en variabelen naar de server gestuurd. De executie gaat dan daar verder.
Dit vereist natuurlijk wel dat je daar rekening mee houdt bij het coden, door serverfunctions en client functions zo veel mogelijk te scheiden.

de volgende code is dus bijzonder inefficient omdat steeds omstebeurt een serverfunction en een clientfunction wordt aangeroepen: (mysql_* is server, $window is client)

PHP:

$result = mysql_query(...);
while($row = mysql_fetch_object($result)) {
  $window->status = $row->veld;
  sleep(1);
}

Om dit soort problemen te voorkomen is er dus een databaselayer ontworpen (deels door D2k, deels door hyperion):

PHP:

$sql = new dbconnection(...); 
// de constructor is forced serverside... wachtwoorden komen dus nooit op de client terecht.
$sql->prepareQuery("SELECT * ....");
$sql->SetOption("client available");
$sql->execute() or die("Sorry...");

while($row = $sql->fetch()) { // sql is nu clientside
  $window->status = $row->veld;
  sleep(1);
}

In feite gebeurt hier het een en ander asyncroon: de query wordt uitgevoerd, en de eerste resultaten worden direct naar de client gestuurd. Fetch blockt tot er gegevens bechikbaar zijn.

edit:
Ik zie hier net dat de CVS niet compileert... Is iemand vergeten wat te submitten?

[D2k]

waar ik wel aan wil toevoegen dat ik vast blijf houden aan mijn coding style. dat kvdveer nou de "java" versie gebruikt moet ie zelf weten, ik doe het liever zo:
(dat zouden we btw kunnen verplicht maken )

PHP:

<?
$sql = new dbconnection(...);  
// de constructor is forced serverside... wachtwoorden komen dus nooit op de client terecht. 
$sql->prepareQuery("SELECT * ...."); 
$sql->SetOption("client available"); 
$sql->execute() or die("Sorry..."); 

while($row = $sql->fetch()) 
{ 
     // sql is nu clientside 
     $window->status = $row->veld; 
     sleep(1); 
}
?> 

[Creepy]

* Creepy is bezig met een LCD driver voor de PHP plugin.. is op het moment een patch/toevoeging op de source. Ik hoop deze nog geintergreerd te krijgen in de uiteindelijke versie, als dit niet lukt dan plaats ik de patch op m'n site.

PHP:

$lcd = oLCD("HD44780");
$lcd->setport(0x0378);
$lcd->setsize(20,2);
$lcd->settext(0,0,"Boe!");
$lcd->refresh;

LCDinf PHP is ook al in de maak

[kvdveer]

Creepy schreef op 11 November 2002 @ 09:34:
* Creepy is bezig met een LCD driver voor de PHP plugin.. is op het moment een patch/toevoeging op de source. Ik hoop deze nog geintergreerd te krijgen in de uiteindelijke versie, als dit niet lukt dan plaats ik de patch op m'n site.

LCDinf PHP is ook al in de maak

Wat ik me afvraag... hou je er rekening mee dat ook de server een lcd-tje kan hebben?

[HunterPro]

kvdveer schreef op 11 November 2002 @ 09:37:
[...]


Wat ik me afvraag... hou je er rekening mee dat ook de server een lcd-tje kan hebben?

Daarvoor heeft die die adressering op regel 1 zitten...duh

[Creepy]

kvdveer schreef op 11 November 2002 @ 09:37:
[...]


Wat ik me afvraag... hou je er rekening mee dat ook de server een lcd-tje kan hebben?

Ow fuck.. ding werkt nu alleen client-side... server side zit je ook weer met de benodigde rechten die je nodig hebt om dat ding te kunnen installeren..
hmm..

ik kan wel een optie bijmaken tijdens het creeren voor clientside/serverside.

Ah.. nee wacht )

PHP:

$LCD=new cLCD(""); // c = client
$LCD=new sLCD(""); // s = server

[Creepy]

|HunterPro| schreef op 11 November 2002 @ 09:38:
[...]

Daarvoor heeft die die adressering op regel 1 zitten...duh

Adressering op regel 1? Nee man, dat is het type LCD!

[kvdveer]

Creepy schreef op 11 november 2002 @ 09:41:
[...]

Ow fuck.. ding werkt nu alleen client-side... server side zit je ook weer met de benodigde rechten die je nodig hebt om dat ding te kunnen installeren..
hmm..

ik kan wel een optie bijmaken tijdens het creeren voor clientside/serverside.

Ah.. nee wacht )

PHP:

$LCD=new cLCD(""); // c = client
$LCD=new sLCD(""); // s = server

Check even de coding guidelines: niet te veel afkorten. LCD kan wel want dat is ingeburgerd, maar c en s is n`et iets te kort.

[HunterPro]

Creepy schreef op 11 November 2002 @ 09:42:
[...]

Adressering op regel 1? Nee man, dat is het type LCD!

okee, ik ga wel weer terug naar W&G...

[Creepy]

kvdveer schreef op 11 november 2002 @ 09:43:
[...]

Check even de coding guidelines: niet te veel afkorten. LCD kan wel want dat is ingeburgerd, maar c en s is n`et iets te kort.

* Creepy pakt de guidelines er ff bij..

Hmm.. ja.. je hebt gelijk.... dan toch maar als optie

PHP:

$lcd = new LCD("clientside","HD44780");

[kvdveer]

Creepy schreef op 11 November 2002 @ 09:44:
[...]


* Creepy pakt de guidelines er ff bij..

Hmm.. ja.. je hebt gelijk.... dan toch maar als optie

PHP:

$lcd = new LCD("clientside","HD44780");

Hmmm. parse error... Schiet eens op!

[Creepy]

|HunterPro| schreef op 11 November 2002 @ 09:44:
[...]

okee, ik ga wel weer terug naar W&G...

Bemoei jij je nou maar met het GEBRUIK van de PHP plugin, i.p.v. de ONTWIKKELING er van

[jelmervos]

Compileert de CVS alweer?

[D2k]

Delphi schreef op 11 november 2002 @ 09:48:
Compileert de CVS alweer?

tis mijn schuld geloof ik
en mijn code ligt thuis

* D2k trekt het boetekleed aan

[Creepy]

Wie moet ik trouwens mailen voor het intergreren/accepteren van mijn LCD patches?

[kvdveer]

Delphi schreef op 11 November 2002 @ 09:48:
Compileert de CVS alweer?

Nee, Ik gebruik nu de CVS van gisteren, die compileert wel... Nu maar hopen dat ik niet aan een module werk waaraan vanancht wijzigingen zijn gesubmit...

[wasigh]

kvdveer schreef op 11 november 2002 @ 09:43:
[...]

Check even de coding guidelines: niet te veel afkorten. LCD kan wel want dat is ingeburgerd, maar c en s is n`et iets te kort.

Die code guidelines vallen zeker onder "er is niets gedocumenteerd" van Drm

En de interne communicatie loopt via GoT zeer interressant! Nu begrijp ik ook beter waar jullie het in A61 over hadden!

Maar waarom mag creepy wel zijn LCD ontwikkelen op de CVS code, krijg ik geen toestemming voor een OptimizedJavaPhpBridge? (maar dan goed! en niet dat brakke van PHP zelf!)

[D2k]

wasigh: hij was eerst. we moeten niet teveel tegelijk aanpakken nou

[wasigh]

D2k schreef op 11 november 2002 @ 10:04:
wasigh: hij was eerst. we moeten niet teveel tegelijk aanpakken nou

[Creepy]

Welke toestemming???
Ding uit CVS halen (werkend is wel handig ), en gewoon je eigen uitbreiding maken. M.b.v. path en diff heb ik van mijn code een losse patch gemaakt die op de CVS van zaterdag avond prima werkt. SOurce downloaden, uitpakken, patch applyen en gaan. Kheb geen toestemming gevraagd

[kvdveer]

Maar JIJ hebt write access IVM die bufferoverrun begin dit jaar (nog bedankt trouwens), wasigh niet.

[Creepy]

kvdveer schreef op 11 november 2002 @ 09:46:
[...]

Hmmm. parse error... Schiet eens op!

He.. rustig.. dat implementeer ik vanavond of morgenavond pas. Naast GoT werk ik ook nog

[Creepy]

kvdveer schreef op 11 November 2002 @ 10:12:
Maar JIJ hebt write access IVM die bufferoverrun begin dit jaar (nog bedankt trouwens), wasigh niet.

Tja.. als D2k niet zo stom was geweest dat ding te introduceren, en jij hem niet gezien had, had ik ook geen write access gehad..

Maar mijn LCD zooi zit nog niet in de CVS..

[wasigh]

Ik heb niet eens ReadAcces!

tja als julllie mijn hulp niet willen, dan schrijf ik wel mijn eigen plugin...

[kvdveer]

wasigh: mail me even, ik heb vanavond of morgen wel tijd om het er in te bouwen...

[SchizoDuckie]

Okee jongens, wanneer gaat deze naar de HK?

[D2k]

Papa Eend schreef op 11 november 2002 @ 10:24:
Okee jongens, wanneer gaat deze naar de HK?

als je zo graag in de HK komt, blijf daar dan ook. Dit is en blijft een TECH forum. danku

[chris]

ik heb ff een artIntelligence plugin geschreven, hoop dat ik het dev-team kan joinen. Door mijn plugin hoeft niemand meer code te schrijven! Het is gewoon:

PHP:

$artIntelligence=new artIntelligence("client");
$artIntelligence->start();

als de gebruiker dus graag een forum wil zien verschijnt er automatisch een forum, en als de gebruiker liever een gastenboek wil zien dan verschijnt dat automatisch. Waar moet ik m'n plugin uploaden?