> В данном случае имеем полубесполезный и очень узко заточенный под гуглопротоколЕсли нечто стандартизировано W3C оно очевидно уже не гуглопротокол.
> "вид коммуникаций", который придётся безусловно фолбечить, если не
> работает хттпмерзкий QUIC.
Или не придется. Раньше вон фалбэчили если XHR не умеет, а сейчас кто этим будет заниматься?
> возможностью например установки системным администратором списка разрешённых хостов
> и сокетов. Вне пользовательского интерфейса.
Синдром вахтера в жесткой форме. Лечится гильотиной. В более легких формах - пачкой злобных юзерей, которые придумают что можно делать с вонючкой-саботажником.
> Потому что те же вёбсокеты уже тоже профигачивают в дуду, и в
> итоге все эти сокетообразные механизмы ничем не лучше прямого открытия сокета.
Я не понимаю термина "профикачивают в дуду". Ими все же не очень получится вообще совсем откровенный спам на вон тот чисто-TCPшный сервак, но с другой стороны можно открыть tcp-подобный сокет и кидать по нему данные вне HTTPшных абстракций (кто сказал что HTTP хорошо маппится на любую задачу?)
> Более того, в рамках QUIC соединение к третьей стороне невозможно, если у
> тебя не прокся на фронте, а значит опять ещё более узенькое применение в угоду
> гуглям и флейру.
Я не понимаю про какие третьи стороны спич. Интернет всегда был соединением IP:port <-> IP:port. Третьи стороны в эту схему никогда не входили.
> Толкать это как стандарт? Ну, можно, если с этого что-то имеешь,
Я вижу для себя более эффективные серверы, более вменяемый flow control и отсутствие нужды хранить буфера под явную опциональщину типа периодических апдейтов.
> в этом позиция "стандартёра" понимаема, да.
А ваша позиция - в чем? Вредительство, саботаж и доказательство что проблем нет или накрайняк обойдемся более быстрыми лошадьми, с отличиями в основном в цвете гривы?
