- abyss
- apache
- cherokee
- hiawatha
- lighttpd
- microsoft iis
- mongoose
- nginx
- thttpd
- tux webserver
A módosítási kérésekre ugyanazok a szabályok vonatkoznak, mint a kategória szavazásra!
Példa:
Ha az foo helyett izébigyó-t szeretnél, akkor:
- foo
+ izébigyó
Ha az tux webserver helyett foobar-t, akkor:
- tux webserver
+ foobar
és így tovább.
Ahol "?" van, ott értelemszerűen lehet javasolni jelöltet az üres helyre.
- 2854 megtekintés
Hozzászólások
"kedvenc http szerver" módosításokat ebbe a szálba (a válasz linkre kattintva) kérem. Egy válasz egy javaslatot tartalmazzon!
Ebből a szálból a kiírásnak meg nem felelő javaslatok és egyéb hozzászólások törlésre kerülnek!
--
trey @ gépház
- abyss (vagy akarmelyik masik, amelyik tavaly gyeren szerepelt)
+ caudium
(ha nagyon bunko akarnek lenni, az is lehetne ezen felul, hogy:
- mongoose
+ thy
De utobbirol szerintem kb 10 ember hallott, ezek kozul is csak nekem kedvencem :P)
Johetnek en is a WebRick-kel, de lehurrognanak, hogy alkalmazasszerver, meg hogy az nem is szerver. Persze a valosag az, hogy nem alkalmazasszerver, es egy par soros program mar kepes static file servert csinalni belole, directory index-szel meg minden kutyafulevel.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
A kulonbseg az, hogy caudium es thy webszerverek, nem alkalmazasszerver egyik sem.
Mi szamit webszervernek? Ami statikus kontentet kiszolgalt HTTP/1.1 protokollon? Mert erre egy egyszeru alkalmazasszerver is kepes. A kulonfele scripting meg kulonfele modulok tamogatasa opcionalis dolog, nem az teszi a webszervert azza, ami.
Az szamit webszervernek, ami azt mondja magarol, hogy o az, es ami miatt nem rinyalna itt senki, hogy dehat az nemaz ;)
Szerintem az amelyik magát csak pecs-nek hívja (a patch-e) és a hiawatha nem webszerver. Meg a lighty sem.
Szóval ennek így semmi értelme :-)
Erdekes modon, azert az emberek tobbsege az apacsot elfogadja webszervernek megis. OMG, lehet mind hulyek vagyunk?
Nem vagytok mind hülyék, csak próbáltam jelezni, hogy egy eleve érzelmekre alapozott szavazásnál nem szabad kihagyni a "definíció" megadásánál a "dafke" szavazókat.
Azert legyunk racionalisak: tobben sirnanak hogy $random_application_server nem webszerver, mint ahanyan sirnanak hogy apache nem az. Utobbiakat kirohognenk. De ha annyira akarod, osszehozok neked egy olyan megfogalmazast amibe tenyleg nem lehet majd belekotni.
De egy szusszra elolvasni se. Szerintem nem eri meg hogy ezzel szivasd magad ;)
- hiawatha
+ LiteSpeed
- hiawatha
+ LiteSpeed
-hiawatha
+jetty
+1, jetty legyen benne
csak ha a tomcat is.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
minek? ott a glassfish ;)
Akkor gondolom te koveteled a listara a fenti ketto melle a glassfish-t is.
A legutobbi adataim szerint a 3. lenne, a 3 kozzul.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
persze, mert nem olyan trivialis, mint a tomcat, es a sok looser nem tudja beallitani.
Ez valójában egy IQ-teszt, hogy a sok tudatlan barom nehogymá ezt használja tomcat, jetty, resin vagy jboss helyett.
nem ertem mit keres a listan a jboss... :)
Neked azt még nem sikerült bekonfigolni? :D
de, csak en ruhellem az xmlt, pl, es mikor legutobb neztem, meg konyekig abban kellett turni, ha barmit akartal.
Penig az xml az enterspájz. Gondolom akkor nem spring-en nevelkedtél, és a soap-tól is ráz a hideg :)
jol latod a helyzetet :-)
a springtol is raz a hideg, de mar rajottek ok is, hogy az xml az egy halott szar (az esetek 99.9% -aban overkill, hacsak nem kell validalnod), es az annotaciok a kiralyak :-)
Marmint a spring esetek 99.9% -ban , vagy az osszes esetben ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
az xmlt baromi lassu eloallitani, es parsolni is.
engem kiraz a hideg, amikor valaki csinal egy webszervizt, es a SOAP envelope nagyobb, mint a hasznos payload... :)
Nyilván, én is többek közt emiatt utáltam eleinte a webservice-t, bár egy ws esetében sem az xml műveleteknél van a szűk keresztmetszet.
Konfigurációknál meg gyakorlatilag mindegy, és asszem ez volt inkább a képben. A soap-ot amiatt emlegettem, mert jópár éve, amikor fejlesztőket küldtünk sun certified j2ee tanfolyamra, akkor az idő nagy százalékát az xml babrálás töltötte ki, és ebből mára talán csak a soap maradt meg, hálistennek már csak mint tudatalatti réteg.
Mit hasznalnal SOAP helyett:
Kovelemenyek:
- nyelv fuggetlen
- platform fuggetlen
- szabvanyosnak tekintheto
- 10/sec request/responost elhanyogalhoto tobblet CPU terhelessel szolgal ki
- nem kovetelmeny, hogy http felett mukodjon
Megbuktak:
- java (oreg) RMI: alig hasznalhato mas eszkozzel
- CORBA: onmagval is nehezkesen kompatibils
- pickle: teljesen csak pythonban egyszeru kezelni, nem szabvagy
Szoba johetne, de XML:
- XML-RPC: szinten xml -de a SOAP -tol konyebb
(- XMPP ??? )
YAML/JSON alapokon ?
DBUS wire protocol ? (a wire protokol egesz hasznalhato, es hordozhato CORBA -hoz kepest mindenkepp)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
ASN.1
BER vagy DER
RESTful ws spring-el :) Bár alapból xml-t használ, rá lehet venni json kezelésre is
+1, HTTP feletti JAX-RS JSON-al a kiraly. a 10req/s meg viccnek szanta turul, gondolom. :)
Nem teljesen viccnek.
A legtobb lassu alkalmazas fuggetlenul eszkoztol, azert bizonyult lassunak, mert valahol egyesevel keregetett adatokat (messzirol), a vices az, amikor a mar hasznalt framework van igy ossze takolva.
Ahol tenyleg sok kis keres kell, ultra low latency-vel, ott meg akkor szoktak sirni az emberek, ha a szoszatyar protokoll miatt nem fer be egy ethernet framebe (egybkent szinte mindegy menyire szoszatyar, az ethernet lesz a lasssu, nem a cpu nem bir szot fosni).
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
Thrift, protobuf?
A magam részéről attól vérzik be az agyam, amikor van egy osztály 20 sor kóddal, és 40 sor annotációval. A kettő között van a megoldás, bár...
Amikor jboss-t kell hurcolni, többszörözni, példányokat összehasonlítani, akkor öröm és boldogság az a szar xml. Amikor a kismillió deployment egyikét kell ASAP helyrerángatni, akkor bebaszna, ha annotációkat, meg osztályokat kéne faragni úgy, hogy eltérő jre-n futnak, amikor az xml módosítása 5 perc alatt kész. WS-t viszont semmi pénzért nem csinálnék annotáció nélkül, de azt is meg lehet nézni, hogy spring-es fejlesztők milyen arányban használnak xml-t, annotációt, vagy java configot (többségében xml-t, a sok barom)
valahol a ketto kozott => Java EE 6 :)
Épp tegnap röhögtem rajta, amikor átnéztem egy cikk apropójából. Nem épp erre gondoltam, de sokan mások sem, bár vannak olyan hangok, hogy a framework-ök korának leáldozott. Vicces.
Jó látni, hogy vesznek át ötleteket a külsős framework fejlesztőktől, de még mindig nem az igazi :)
engem a springtol raz a hideg, teged ettol. izlesek es pofonok :-)
mar csak a cpp fejlesztoknek kene eszrevenni, hogy vannak feladatok, amit ha vert hugyoznak se fognak megcsinalni normalisan :)
Did you mean: loser
+1
-mongoose
+boa
Referenciakent a mult evi eredmeny mielott valaki ertelmes megprobalna kivetetni az apacsot/lightyt :)
http://hup.hu/szavazasok/20091130/hovd_2009_kedvenc_http_szerver
--
Why do Muslims blow themselves up to meet 72 Virgins, when they can just get a job in IT!
Jól értem hogy servlet konténerekre és alkalmazásszerverekre itt nem szavazunk?
Csak mert nem kevésbé furcsa állatok mint pl a funkcionális programnyelvek a programnyelves kategóriában, sőt, szerintem szélesebb körben használják.
Ugy latszik, nem sikerult megerteni a szavazas mogott rejlo logikat. Nem baj, majd jovore.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
Sosem fogom megérteni miért jó fölényesen és tuskó módon beszólni valakinek, aki csak épp érdeklődött a dolgok jelenlegi állásáról.
De biztos én vagyok különc.
amikor 50-edjére kérdeznek/írnak valami banálisat, akkor már nehéz birkatürelműnek lenni.
Raadasul tobb evre visszamenoleg kikereshetoek a savazasok....Amikor backup megoldast kerestem, ez volt az egyik tampont.
Így van. És mennyivel szórakoztatóbb hozzászólások százait gerjeszteni egy olyan kérdésre, amire ennyi is elég lett volna válaszképpen "Igen", bár az nem lett volna olyan "szakértősös"
Mint ahogy a disztribúció szavazásban kevés a 10 opció, itt meg úgy érzem, hogy sok.
Tessék olyan kategóriákat javasolni jövőre, ahol a 10 pont elég. :)
--
Don't be an Ubuntard!
Kedvenc hét törpe? :-)
Fuszenecker Róbert
És majd berakjuk a maradék három helyre Hófehérkét, a banyát meg a vadászt? És akkor majd jönnek sírni, hogy a tükör hol marad. :)
--
Don't be an Ubuntard!
A tükör még csak-csak, de a herceget ki ne hagyd, meg a sok állatkát akik segítettek takarítani! Nekem a mókus a kedvencem meg a teknős :-)
--
falura elmegy, városban meg úgy sem nézik...
Hat de vazze, a LOROL MINDENKI ELFELEDKEZIK?
Szerintetek, de most oszinten, odaert volna a herceg a LO nelkul, mielott a torpek elassak Hofeherket? Hat perszehogy nem. A LO kerem alassan a mese kulcsfiguraja, ot kihagyni BUN!
Megall az ember esze, egyesek milyen konnyen elfeledkeznek errol... hihetetlen, de most komolyan!
+1 a lora
- Hófehérke
+ ló
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
- tux
+ yaws
-apache
+apache2
:)
Az idei HOVD kommenteket azért be lehet kereteztetni. :)
--
2e845cb4c3a5b5bd6508455b1739a8a2
"A tavalyi jobb volt" es "ez is evrol evre szarabb lesz" es "higul a hozzaszolasok szakmai szinvovanale" es ...janem, ez nem a modoros blog.
--
http://www.micros~1
Attól, hogy kezd közhellyé válni, attól még gyász.
--
2e845cb4c3a5b5bd6508455b1739a8a2
Teny. De valtoztatni ugyse tudok rajta, akkor minek gyorsitsam a folyamatot?