Re: Udfordring

On 12/05/2010, at 09.14, Michael Zedeler wrote:

> On 2010-05-12 08:10, Jonas B. Nielsen wrote:
>> Hej Michael,
>> 
>> Se nedenfor,
>> 
>> On 11/05/2010, at 21.55, Michael Zedeler wrote:
>> 
>> 
>>> On 2010-05-11 21:43, Jonas B. Nielsen wrote:
>>> 
>>>> Jeg har en lidt seriøs udfordring, som jeg vil høre om der er nogen der kan bidrage med løsningsforslag til:
>>>> 
>>>> Jeg har skrevet en Catalyst applikation som implementerer en egen specificeret protokol.
>>>> 
>>>> Valget af Catalyst blev gjort på følgende grundlag:
>>>> 
>>>> - Stabilt framework
>>>> - Nemt at teste
>>>> - HTTP baseret
>>>> - Indlejring i eksisterende platform (Apache2/mod_perl2 eller andet)
>>>> - Understøttelse af SSL
>>>> 
>>>> Protokollen implementerer en række egne fejlkoder som går udover hvad som er defineret i HTTP.
>>>> 
>>>> Jeg valgte af gammel vane at bruge Apache2 med mod_perl2 som engine. Dette viste sig dog at give visse udfordringer. Apache2 understøtter nemlig ikke egne fejlkoder alt som ikke er defineret i HTTP og alt ukendt bliver oversat til 500.
>>>> 
>>>> Det operativ system vi benytter supporterer ikke længere Apache1 med mod_perl, men det kan være en sidste udvej at forsøge at få dette til at virke,men...
>>>> 
>>>> Jeg har forsøgt med lighttpd med FastCGI, men der er samme scenario som for Apache2.
>>>> 
>>>> Jeg har grublet over følgende alternative løsninger:
>>>> 
>>>> - Egen server, den skal dog understøtte SSL, så jeg er blevet lidt i tvivl om det er den bedste vej at gå, skalerbarhed kan blive et problem.
>>>> - En POE baseret løsning (kan benytte SSL med lidt tweaks), er i tvivl om skalerbarhed dog
>>>> - Nginx? - I dunno
>>>> 
>>> Protokollen burde jo være HTTP-kompatibel. Det ville løse samtlige af dine problemer ovenfor (pånær at I ikke kan bruge mod_perl).
>>> 
>>> Ellers ville jeg gå efter egen server med en SSL-frontend af en art, men nu ved jeg jo ikke hvad det skal bruges til og hvordan applikationen er skrevet. Hvis I benytter en protokol som ikke rigtig er HTTP, er det en kamp imod vindmøller at vedlige en applikation, der benytter en webserver.
>>> 
>> Ang. kampen mod vindmøller så er jeg enig.
>> 
>> Pt. arbejder jeg dog på at få version 1 sat i vandet, så kan jeg arbejde på version 2, som så kan være en mere langsigtet løsning. Argh jeg begynder at lyde som vores statsminister: "Det er et meget fint forslag, men det løser ikke Danmarks problemer nu og her"
>> 
>> Jeg ser på at benytte Apache's protocol handlers til en langsigtet løsning, men jeg havde håbet på en mere letvægtig løsning.
>> 
> Men så er du jo stadigvæk igang med at lave en ny protokol som ikke er helt HTTP-kompatibel. Der er masser af måder at tilpasse HTTP, så den kan overføre statuskoder i headerne, uden at man ender med en anden protokol (se f. eks. Kelis forslag).
> 
> Det ligner stadigvæk en "hvordan bruger jeg bedst denne skrutrækker som en skovl"-diskussion. Brug en skovl :)
> 
> Er det en stor opgave at ændre protokollen tilbage til HTTP?
> 
> I hvert fald kunne det være mere interessant at høre hvad det er, der er behov for at kunne, som HTTP ikke kan.
> 
> Mvh. Michael.
> 

Heh, I am just the guy with the shovel.

HTTP er nemt at arbejde med rent klient mæssigt, derfor valget af HTTP regner jeg med.

Det som HTTP ikke understøtter (i Apaches og lighttpds tilfælde) er fejlkoder som ikke er defineret i RFC. En work-around er muligvis mulig, se kommunikationen med Anton.

Vi har bare flere fejlkoder end specificeret for HTTP, så Keli's forslag er helt klart et godt forslag.

jonasbn