SPDY znajdzie się w standardzie HTTP 2.0?

Hmm bardzo ciekawy pomysł

stylów CSS, nie styli

No fajnie, tylko zastanawiam się czy nie jest to tylko fanaberia kilku firm celem ... bo ja wiem zwiększeniem objętości specyfikacj czy jak?

@Shaki81: chyba nie mówisz serio :) Wiadomo, że chodzi o kasę. Sprawniej działające WWW -> więcej kasy z usług internetowych. A przy okazji promocja siebie, tzn. Google, jako innowacyjnej firmy. Pracownicy Google musieli by być wielkimi nerdami, żeby mieć fanaberię polegającą na modyfikacji jakiegoś zakurzonego RFC.

@Shaki81?
Fanaberia? Nie, po prostu interes Google.
Szybsze otwieranie się stron oznacza szybsze ich przeglądanie. Na wielu stronach są reklamy, które stanowią główne źródło przychodów Google. Więc chyba oczywiste, dlaczego chcą, żebyśmy tych stron przeglądali więcej, zamiast marnować czas czekając na ich załadowanie.

Szybsze ładowanie strony = więcej reklam wciśniętych w tym samym czasie.

@Jaahquubel_ ogólniej to szybsze ładowanie stron -> mniejsze obciążenie serwerów -> większy zysk ;)

E tam. Trzeba wywalić cały stos protokołów i zastąpić go jednym a porządnym. I co 15 lat zmieniać, bo czasy i możliwości się zmieniają. Dzisiejsze prędkości na X lat będą niewielkie, np. 10000 Tbps, i trzeba z tego korzystać. Pomyślmy wprowadźmy protokół NICI :)

Dzielony oktetami.
(adres zmiennej długości: src)(adres zmiennej długości: dst)(typ CRC zmiennej długości)(CRC zmiennej długości)(długość paczki zmiennej długości)(lista typ-wartość parametrów opcjonalnych, patrz przykład z CRC)(dane...)

Zmienna długość polega że nie ma ustalonej wielkości pola, minimum to 2 oktety. Innymi słowy pole składa się z długości pola wyrażonego jedynkami z przodu i właściwego pola wartości, np. 0b1111110 0x01 0x02 0x03 0x04 0x05 0x06; ilość jedynek z przodu oznacza ile oktetów jest przeznaczonych na dane. Upraszcza to analizę protokołu czyli uprości sprzęt a zapewni nieograniczone możliwości, przy niewielkiej straci objętości. Oczywiście ilość poprzedzających jedynek może być nieograniczona :) Ale muszą kończyć się zerem i być dzielone oktetami.

W opcjonalnych parametrach zaimplementuje się wszelkiej maści ulepszenia, jak np. retransmisje, optymalizacje dla aplikacji, szyfrowania, itp. Wartości typów będzie ustalać jedna organizacja, czyli będą to ustandaryzowane typy. Nigdy więcej wartości zarezerwowanych. W końcu nie ma co rezerwować, bo ograniczeń nie ma. Aha, długość wartości za typem określa sam typ.

Dwa typy będą specjalne. VENDOR START i VENDOR END. Między tymi typami będzie lista typów specjalna dla zastosować różnych vendorów. Także numerowanych od 1 z wyłączeniem specjalnej wartości dla VENDOR END. Oczywiście typ VENDOR START w wartości będzie VENDOR ID zmiennej długości :) Inne typy mogą mieć stałą wielkość (ustalany przez TYP w specyfikacji)

W ten sposób protokół będzie prosty do napisania "w sprzęcie". Bo będzie jeden specjalny parser dla listy typ-wartość i wystarczy zwykły switch-case by oprogramować wartości typów.

W szczególności jeden z typów powinien nazywać się PORT i za wartość winien mieć numer portu. I jeszcze od razu typ THREAD, który w wartości będzie mieć numer wątku do którego winny lecieć dane w jednym porcie. Takie jakieś multipleksowanie.

Mam nadzieję że protokół jest jasny i nieograniczony.

Protokół NICI jest na licencji "róbta z tym co chceta; nawet praw autorskich nie potrzebuję tu". Bo czy ktoś go opatentuje czy nie ja go i tak zaimplementuję jeśli zechcę. A na razie nie chcę, bo mam inne zajęcia, ale chcę coś zrobić dla dobra ludzkości :)

Aż ciśnie się na usta [klawiaturę?]: "Dopiero teraz?"
Wg mnie to za mało, aby uczynić HTTP 2.0, raczej 1.5.

"Obecnie przeglądarka tworzy nowe połączenia dla każdego elementu strony internetowej, który jest oddzielnym plikiem. Konieczne są więc oddzielne połączenia nie tylko dla grafiki, obiektów Flash czy filmów, ale też dla skryptów JavaScript i stylów CSS, które nie są osadzone w kodzie strony internetowej."

Proszę sprawdzić nagłówek HTTP 1.1 Connection: keep-alive. Czy powyższe stwierdzenie jest nadal prawdziwe?

bardzo dobry pomysł i mam nadzieję że to będę mógł przetestować zanim przez ACTA internet będzie filtrowany, to wtedy i tak tego nie odczujemy

@-ignorant-

HTTP 1.1 zakłada że każde połączenie jest trwałe (co przy Apache 2.2 oznacza 5 sek).