Onderwerp: Lange GET parameters?

On Thu, 03 Jul 2003 02:45:35 +0200, John Bokma
<postmaster@castleamber.com> wrote:

>Joop wrote:
>
>> On Tue, 1 Jul 2003 21:05:32 +0200, uws <uws@xs4all.invalid> wrote:
>>
>>>I <kiv2gv0nlcfsb2rm76bvm2v5geiub71cef@4ax.com>, Joop skrev:
>>>
>>>>Ideeen zijn welkom, maar een query doorgeven over GET lijkt mij de
>>>>beste oplossing, want servlet moet de query genereren, dat kan php
>>>>script niet en het c programma moet via php aangeroepen worden.
>>>
>>>Wat is dat dan voor iets dat Java wel kan en PHP niet? Het genereren van een
>>>string?
>>
>> Je bedoelt het anders :-) De servlet package bevat de logica die het
>> mogelijk maakt de query te maken, dit zijn enkele classes die op hun
>> buurt weer functies bevatten. Het zou dagen kosten om deze over te
>> zetten naar php en bovendien krijg je dan 2 versies van classes die
>> hetzelfde doen, dat lijkt me niet handig.
>
>Stop die PHP shit in je servlet, daar hoort het IMHO ook.
>

Tis geen .net :-) Tis jammer dat er geen forward() methode is die
intern ook een post/get naar een php script kan forwarden, anders was
heel het probleem opgelost.

joop

On Thu, 03 Jul 2003 03:05:23 +0200, John Bokma
<postmaster@castleamber.com> wrote:

>Joop wrote:
>
>> Dat is met een mutex/sync werken, maar dat is niet de bedoeling, er
>

Ik heb niet goed gelezen.

>Dat is wel de bedoeling. Als je C programma altijd het plaatje naar
>hetzelfde bestand schrijft kom je daar gewoon niet onderuit,

Bij elke request word een apart plaatje aangemaakt. Daarom heb ik een
leuke hardeschijf ter beschikking :-)

joop

On Thu, 03 Jul 2003 02:57:24 +0200, John Bokma
<postmaster@castleamber.com> wrote:

>Joop wrote:
>
>> On Tue, 01 Jul 2003 12:56:21 +0200, John Bokma
>> <postmaster@castleamber.com> wrote:
>>
>>
>>>Joop wrote:
>>>
>>>
>>>>On Tue, 01 Jul 2003 11:37:10 +0200, John Bokma
>>>><postmaster@castleamber.com> wrote:
>>>
>>>[snip]
>>>
>>>
>>>>Maar dat gaat juist niet, de servlet kan de query niet uitvoeren, dat
>>>>kan alleen php. Het is namelijk zo dat er alleen een php schil bestaat
>>>>voor een programma wat geschreven is in c wat niet multi threads
>>>>ondersteund, via php benaderen is dus de enigste optie.
>>>
>>>??? Welke database is dat dan? Voor de meeste databases zijn er JDBC
>>>drivers te vinden.
>>
>>
>> De setup is redelijk ingewikkeld, het komt erop neer dat een servlet
>> een webform genereert, een andere servlet handelt de POST af en maakt
>
>> een zoek query. Deze query stuurt hij naar php script, php script
>> roept c programma aan en geeft query door, c programma benadert een
>> speciale postgresql module die de query uitvoert, het resultaat word
>
>Waarom? Dit kan ook vanuit Java. Sterker, er is, weet ik zeker, een
>postgesql driver voor Java... Wat is die module precies en wat doet dat
>C programma? Vertel niet dat dat C programma er alleen maar is om de
>query door te geven aan postgres en die weer terug te geven aan PHP??

de pgsql module introduceert een aantal nieuwe functies en variabele,
deze functies kunnen custom kolom typen uitlezen en parsen en maken
speciale sql queries mogelijk. Het c programma doet de query en parsed
het resultaat naar een plaatje.

>
>> door het c programma omgezet naar een plaatje en bewaart op de
>
>Ah, ok, ook iets wat je zo in Java kan doen hoor. Er is een prachtige
>grafische library in Java. Ik heb keurige servlets gemaakt die allerlei
>mooie grafiekjes maaken :-).

Ging het maar om een grafiekje :-) Nee, het ligt wat ingewikkelder,
het zou maanden kosten om iets soortgelijks te bouwen in java.

>
>> hardeschijf, tot slot geef c programma path naar plaatje door aan php
>
>file-locking? Wie ruimt dat bestand op... oei... ik vrees dat je hier op
>gaat reageren dat altijd "plaatje.gif" wordt gebruikt en zie ik direct
>je "threading" probleem, dat er overigens nog steeds is. Met twee
>browsers op twee computers kan ik vast een keer je plaatje om zeep
>helpen als het zo inelkaar zit als ik vrees...

Nee, nee, er word altijd een nieuw plaatje aangemaakt, daarom is een
grote harde schijf nodig. Cleanup gebeurt met een cronjob, die
verwijderd alle plaatjes < nu - 1dag

>
>> script, die het plaatje op een html pagina zet.
>>
>>
>>>Overigens kan je die PHP schil ook zo in Java namaken. Zou niet weten
>>>waarom niet. PHP kan echt niet meer dan Java. Zelfs als je een
>>>c-programma wilt aanroepen kan dat vanuit Java.
>>>
>>>[snip moet ik even over nadenken, is al laat]
>>
>> Een php script runt bij mij als cgi (niet als .so module), dit
>> betekent dat een php script als hij klaar is alle variabelen vrij
>> maakt. Een servlet kan dit niet, die blijft constant draaien, er is
>
>snap ik helemaal niks van, echt niet.

Is waarschijnlijk niet zo van belang, heeft iets te maken met
multithreads, als php gecomp. is als cgi doet ie het, als php gecomp.
is als module doet ie het niet. Dat is een feit.

>
>> wel een singlethread model, maar dat word afgeraden. Als 2 servlet
>> requests op hetzelfde moment het c programma benaderen en het c
>> programma houd hier geen rekening mee dan gaat het schijnbaar mis. Dat
>
>Natuurlijk. Ook als twee bezoekers op hetzelfde moment je PHP aanroepen...

Schijnbaar niet, maar dat had ik al gezegd.

>
>> is aan servlet kant wel op te lossen door bv mutex/sync, maar dan moet
>> je zelf een hele schil gaan maken voor de c functies, dat kost aardig
>> wat tijd.
>
>Snap er echt niks van. Volgens mij *denk* je een probleem opgelost te
>hebben dat er nog steeds *mega* is, nl het risico dat je plaatje
>verminkt wordt. PHP helpt je daar echt niet vanaf.

Neem maar aan dat het met php goed werkt, orgranisaties die deze
methode gebruiken zijn er zat.

>Het enige dat je zou
>kunnen doen is in PHP een bestand maken dat je lock.file noemt, daar een
>lock op gooien, C programma aanroepen, en lock.file unlocken als je het
>plaatje terug hebt. (Let op! Niet als het C programma klaar is, want dan
>heb je nog steeds een o-shit moment). Hmmm, ik zie hier nog wat problemen.

File locking, dat lijkt me geen goed idee. Heb ik eens problemen mee
gehad met perl (maar dat was in de vroegere jaren) :-)

>
>TIP: genereer het plaatje in je servlet, echt, dan voorkom je zo
>vreselijk veel shit. Ik kan (tegen betaling cq. goodies :-) hier vast
>bij helpen.

Het heeft me een half jaar gekost om de theorie achter het c programma
te leren, het is een nogal speciaal programma dat een erg
specialistisch doel na streeft. Het is me ten oren gekomen dat er een
aan een pure java versie word gewerkt, maar dat duurt nog enkele jaren
(!) voordat deze op het niveau is van het c programma.


joop

On Thu, 03 Jul 2003 09:56:01 +0200, Joop <joop@ikbennietjoop.com> wrote:
> On Thu, 03 Jul 2003 03:05:23 +0200, John Bokma
><postmaster@castleamber.com> wrote:

>>Dat is wel de bedoeling. Als je C programma altijd het plaatje naar
>>hetzelfde bestand schrijft kom je daar gewoon niet onderuit,
>
> Bij elke request word een apart plaatje aangemaakt. Daarom heb ik een
> leuke hardeschijf ter beschikking :-)

Klinkt mij nogal bloated in de oren, je zou kunnen overwegen om met sessions
het plaatje tijdelijk op te slaan.

--
http://spamikaze.nl.linux.org/

Joop wrote:

> On Thu, 03 Jul 2003 02:49:48 +0200, John Bokma
> <postmaster@castleamber.com> wrote:
>
>>Joop wrote:
>>
>>>On Tue, 01 Jul 2003 11:37:10 +0200, John Bokma
>>><postmaster@castleamber.com> wrote:
>>
>>[snip]
>>
>>>Maar dat gaat juist niet, de servlet kan de query niet uitvoeren, dat
>>
>>*waarom* niet?
>
>
> Omdat het c programma het resultaat van de query parsed naar een
> plaatje, dit kan een servlet niet, of je moet het c programma
> herschrijven naar servlet, maar dat ben je een paar maanden bezig.

Wat doet het precies? Wat voor plaatje maakt het? In maanden kan je veel
programmeren hoor :-)

>>>kan alleen php. Het is namelijk zo dat er alleen een php schil bestaat
>>>voor een programma wat geschreven is in c wat niet multi threads
>>>ondersteund, via php benaderen is dus de enigste optie.
>>
>>*waarom*? Pas op met threads en zo, ik kan met 2 browsers heel goed jouw
>>PHP programma vrijwel gelijktijdig aanroepen... als je c programma of je
>>database hiermee niet overweg kan is het einde echt zoek op deze
>>manier... Sterker, dan *moet* je misschien wel een servlet gebruiken of
>>file-locking vanuit PHP..
>
> Andere mensen gebruiken met succes de php schil op grote websites en
> hebben nooit problemen gehad, dus ik kan er van uit gaan dat het met
> php gewoon goed gaat.

Ah, ja, ik herinner mij formmail.pl of zo van ene Matt? Werd ook overal
gebruikt, IIRC.

John

--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
website design tips: http://johnbokma.com/websitedesign/ (preliminary)

Joop wrote:

> On Thu, 03 Jul 2003 02:57:24 +0200, John Bokma
> <postmaster@castleamber.com> wrote:
>
>>Joop wrote:
>>
>>>On Tue, 01 Jul 2003 12:56:21 +0200, John Bokma
>>><postmaster@castleamber.com> wrote:
>>>
>>>>Joop wrote:
>>>>
>>>>>On Tue, 01 Jul 2003 11:37:10 +0200, John Bokma
>>>>><postmaster@castleamber.com> wrote:

[snip]

>>Ah, ok, ook iets wat je zo in Java kan doen hoor. Er is een prachtige
>>grafische library in Java. Ik heb keurige servlets gemaakt die allerlei
>>mooie grafiekjes maaken :-).
>
>
> Ging het maar om een grafiekje :-) Nee, het ligt wat ingewikkelder,
> het zou maanden kosten om iets soortgelijks te bouwen in java.

Kan je vertellen waar het om gaat? Ik kan mij weinig voorstellen dat
*maanden* kost om te ontwikkelen qua maken van een plaatje uit een
database :-). (Misschien zit ik teveel met grafieken in mijn hoofd).

[snip]

>>Snap er echt niks van. Volgens mij *denk* je een probleem opgelost te
>>hebben dat er nog steeds *mega* is, nl het risico dat je plaatje
>>verminkt wordt. PHP helpt je daar echt niet vanaf.
>
>
> Neem maar aan dat het met php goed werkt, orgranisaties die deze
> methode gebruiken zijn er zat.

Het probleem met threading kan soms jaren niet opduiken.. Maar ik
begrijp dat er telkens nieuwe plaatjes worden aangemaakt, ondertussen.
Ik hoop dat dat niet op basis van timestamp oid gebeurd...

>>Het enige dat je zou
>>kunnen doen is in PHP een bestand maken dat je lock.file noemt, daar een
>>lock op gooien, C programma aanroepen, en lock.file unlocken als je het
>>plaatje terug hebt. (Let op! Niet als het C programma klaar is, want dan
>>heb je nog steeds een o-shit moment). Hmmm, ik zie hier nog wat problemen.
>
>
> File locking, dat lijkt me geen goed idee. Heb ik eens problemen mee
> gehad met perl (maar dat was in de vroegere jaren) :-)

? File locking is een uitstekend idee. Problemen worden vaak veroorzaakt
door onbegrip, of door programma's die locks negeren.


>>TIP: genereer het plaatje in je servlet, echt, dan voorkom je zo
>>vreselijk veel shit. Ik kan (tegen betaling cq. goodies :-) hier vast
>>bij helpen.
>
>
> Het heeft me een half jaar gekost om de theorie achter het c programma
> te leren, het is een nogal speciaal programma dat een erg
> specialistisch doel na streeft. Het is me ten oren gekomen dat er een
> aan een pure java versie word gewerkt, maar dat duurt nog enkele jaren
> (!) voordat deze op het niveau is van het c programma.

Klinkt als een hoop marketing poeha. Ik vrees dat je niet mag vertellen
wat dat super specialistische programma precies doet?

John

--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
website design tips: http://johnbokma.com/websitedesign/ (preliminary)

On Thu, 3 Jul 2003 09:10:01 +0000 (UTC), Hans
<nomailwanted@e35203.upc-e.chelle.nl> wrote:

>On Thu, 03 Jul 2003 09:56:01 +0200, Joop <joop@ikbennietjoop.com> wrote:
>> On Thu, 03 Jul 2003 03:05:23 +0200, John Bokma
>><postmaster@castleamber.com> wrote:
>
>>>Dat is wel de bedoeling. Als je C programma altijd het plaatje naar
>>>hetzelfde bestand schrijft kom je daar gewoon niet onderuit,
>>
>> Bij elke request word een apart plaatje aangemaakt. Daarom heb ik een
>> leuke hardeschijf ter beschikking :-)
>
>Klinkt mij nogal bloated in de oren, je zou kunnen overwegen om met sessions
>het plaatje tijdelijk op te slaan.

Het genereren van een plaatje gaat opzich redelijk snel, maar
inderdaad ik zat zelf ook te denken over een soort cache. Het probleem
is alleen dat een plaatje bijna nooit hetzelfde is, je hebt gok ik een
paar miljoen mogelijke plaatjes. Al heb ik gelukkig wel al een paar
ideeen over hoe ik de load wat omlaag kan halen, maar dat hoeft
gelukkig nog niet.

joop

On Thu, 03 Jul 2003 18:03:06 +0200, John Bokma
<postmaster@castleamber.com> wrote:

>Joop wrote:
>
>> On Thu, 03 Jul 2003 02:57:24 +0200, John Bokma
>> <postmaster@castleamber.com> wrote:
>>
>>>Joop wrote:
>>>
>>>>On Tue, 01 Jul 2003 12:56:21 +0200, John Bokma
>>>><postmaster@castleamber.com> wrote:
>>>>
>>>>>Joop wrote:
>>>>>
>>>>>>On Tue, 01 Jul 2003 11:37:10 +0200, John Bokma
>>>>>><postmaster@castleamber.com> wrote:
>
>[snip]
>
>>>Ah, ok, ook iets wat je zo in Java kan doen hoor. Er is een prachtige
>>>grafische library in Java. Ik heb keurige servlets gemaakt die allerlei
>>>mooie grafiekjes maaken :-).
>>
>>
>> Ging het maar om een grafiekje :-) Nee, het ligt wat ingewikkelder,
>> het zou maanden kosten om iets soortgelijks te bouwen in java.
>
>Kan je vertellen waar het om gaat?

Helaas, gaat dat niet.

>Ik kan mij weinig voorstellen dat
>*maanden* kost om te ontwikkelen qua maken van een plaatje uit een
>database :-). (Misschien zit ik teveel met grafieken in mijn hoofd).

Het is niet alleen uit een database, maar ook uit flat files (even
aangenomen dat je dit niet onder database valt).

>
>[snip]
>
>>>Snap er echt niks van. Volgens mij *denk* je een probleem opgelost te
>>>hebben dat er nog steeds *mega* is, nl het risico dat je plaatje
>>>verminkt wordt. PHP helpt je daar echt niet vanaf.
>>
>>
>> Neem maar aan dat het met php goed werkt, orgranisaties die deze
>> methode gebruiken zijn er zat.
>
>Het probleem met threading kan soms jaren niet opduiken.. Maar ik
>begrijp dat er telkens nieuwe plaatjes worden aangemaakt, ondertussen.

Klopt, maar ik werk er al 2 jaar mee en heb er wel vertrouwen in. Het
prog is al in ontwikkeling van 1996 toen was het nog van een subgroep
bij de nasa

>Ik hoop dat dat niet op basis van timestamp oid gebeurd...

Gelukkig niet, anders kun je niet meer dan 1 hit per sec. hebben.

>
>>>Het enige dat je zou
>>>kunnen doen is in PHP een bestand maken dat je lock.file noemt, daar een
>>>lock op gooien, C programma aanroepen, en lock.file unlocken als je het
>>>plaatje terug hebt. (Let op! Niet als het C programma klaar is, want dan
>>>heb je nog steeds een o-shit moment). Hmmm, ik zie hier nog wat problemen.
>>
>>
>> File locking, dat lijkt me geen goed idee. Heb ik eens problemen mee
>> gehad met perl (maar dat was in de vroegere jaren) :-)
>
>? File locking is een uitstekend idee. Problemen worden vaak veroorzaakt
>door onbegrip, of door programma's die locks negeren.

Ik weet niet meer precies hoe het zat, maar file locking was een no
go, misschien was het een bepaalde lib. die het fout deed, dat
herinner ik me niet meer.

>
>
>>>TIP: genereer het plaatje in je servlet, echt, dan voorkom je zo
>>>vreselijk veel shit. Ik kan (tegen betaling cq. goodies :-) hier vast
>>>bij helpen.
>>
>>
>> Het heeft me een half jaar gekost om de theorie achter het c programma
>> te leren, het is een nogal speciaal programma dat een erg
>> specialistisch doel na streeft. Het is me ten oren gekomen dat er een
>> aan een pure java versie word gewerkt, maar dat duurt nog enkele jaren
>> (!) voordat deze op het niveau is van het c programma.
>
>Klinkt als een hoop marketing poeha. Ik vrees dat je niet mag vertellen
>wat dat super specialistische programma precies doet?

Dat klopt, helaas...

joop

On Thu, 03 Jul 2003 17:55:57 +0200, John Bokma
<postmaster@castleamber.com> wrote:

>Joop wrote:
>
>> On Thu, 03 Jul 2003 02:49:48 +0200, John Bokma
>> <postmaster@castleamber.com> wrote:
>>
>>>Joop wrote:
>>>
>>>>On Tue, 01 Jul 2003 11:37:10 +0200, John Bokma
>>>><postmaster@castleamber.com> wrote:
>>>
>>>[snip]
>>>
>>>>Maar dat gaat juist niet, de servlet kan de query niet uitvoeren, dat
>>>
>>>*waarom* niet?
>>
>>
>> Omdat het c programma het resultaat van de query parsed naar een
>> plaatje, dit kan een servlet niet, of je moet het c programma
>> herschrijven naar servlet, maar dat ben je een paar maanden bezig.
>
>Wat doet het precies? Wat voor plaatje maakt het? In maanden kan je veel
>programmeren hoor :-)

Helaas kan ik dat niet vertellen..

>
>>>>kan alleen php. Het is namelijk zo dat er alleen een php schil bestaat
>>>>voor een programma wat geschreven is in c wat niet multi threads
>>>>ondersteund, via php benaderen is dus de enigste optie.
>>>
>>>*waarom*? Pas op met threads en zo, ik kan met 2 browsers heel goed jouw
>>>PHP programma vrijwel gelijktijdig aanroepen... als je c programma of je
>>>database hiermee niet overweg kan is het einde echt zoek op deze
>>>manier... Sterker, dan *moet* je misschien wel een servlet gebruiken of
>>>file-locking vanuit PHP..
>>
>> Andere mensen gebruiken met succes de php schil op grote websites en
>> hebben nooit problemen gehad, dus ik kan er van uit gaan dat het met
>> php gewoon goed gaat.
>
>Ah, ja, ik herinner mij formmail.pl of zo van ene Matt? Werd ook overal
>gebruikt, IIRC.

Dit vergelijken met formmail is een krom maar dat kun je niet weten,
het is nu al zo'n 7 jaar in ontwikkeling (formmail waarschijnlijk ook
maar neem maar aan dat het goed getest is.


joop

Joop wrote:
> On Thu, 03 Jul 2003 17:55:57 +0200, John Bokma
> <postmaster@castleamber.com> wrote:

[snip]

> Dit vergelijken met formmail is een krom maar dat kun je niet weten,

Sorry, maar als ik er zo over hoor is die vergelijking meer dan terecht,
ik bedoel hele queries doorgeven via een GET is net zo extreem als al
die rarigheden in formmail. De vergelijking is dus, naar wat ik begrepen
heb, helemaal niet zo krom.

> het is nu al zo'n 7 jaar in ontwikkeling (formmail waarschijnlijk ook
> maar neem maar aan dat het goed getest is.

Mocht je hulp nodig hebben, en ikzelf vrees dat dat best wel nodig is
als ik zo lees e.d. kan je mij prive mailen. Ik heb er totaal geen
moeite mee om een geheimhoudingsverklaring te tekenen tenzij je iets
heel geks aan het doen bent [1] :-)

John

[1] wereld opblazen of zo :-)

--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
website design tips: http://johnbokma.com/websitedesign/ (preliminary)