Из рода "Слон ебёт свинью" :)

ШТО? =)

Учитывая что у плюсов нет даже стандартизированного ABI (объектники или просто торчащие наружу классы использовать из разных компиляторов не получится) — очень точное выражение

/start@virtsex_bot

Hellorust.com/emscripten/

Походу они доступ к DOM даже получают

чёт жоский js на выходе

31кс

весь рантайм в js перепечатывается (даже simd)

К разве не в wasm?

http://www.hellorust.com/emscripten/demos/07-webplatform/app.js

без малейшего понятия как должен работать wasm

теоретически могу предположить, только, что это бинарные данные, особым способом интерпретируемые js движком

но тут читаемый js описывает даже phtread

да уж

Кстати а в чем плюс такой генерации REST интерфейса https://github.com/rejectedsoftware/vibenews/blob/master/source/vibenews/admin.d ?

приблизительно на 28 тысяче там не особо читабельный код

просто до этого я думал что рест надо так генерить: http://vibed.org/api/vibe.web.rest/registerRestInterface

так это не rest

да? А что это и в чем тогда фишка?

Это просто ЧПУ?

что есть чпу?

Человекопонятные урлы

очень странная абревиатура

потому что первое что приходит в голову это https://ru.wikipedia.org/wiki/%D0%A7%D0%B8%D1%81%D0%BB%D0%BE%D0%B2%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B5_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5

Это да. Просто в сео обычно это ЧПУ называют

все генераторы интерфейсов это какой-то код с какими-то ограничениями

а тут как без esp и на ручной коробке

и по такой как в мск погоде)))

а что этот подходпозволяет в данном случае то?

я не вчитывался

нужно знать, что точно позволяет генератор web интерфейса

прям досконально

и тогда можно будет сказать, что конкретно они тут обошли в этой схеме

как минимум они отказались от генератора

Мне кажется или тут они из запроса вытаскиывают разные поля которых нет в json ?

типа тело пост-запроса и тд

возможно они не будут особо менять тот код, который используется в этом admin, а генератор будут переписывать

а в ресте только json один можно гонять

Мне кажется или тут они из запроса вытаскиывают разные поля которых нет в json ?

не особо понял

во первых это не rest)

ну прилетает пост запрос в нем куча данных есть еще кроме джейсона

а если бы был рест мы только с джейсоном могли работать

ну не rest это!)

info.page = ("page" in req.query) ? to!int(req.query["page"])-1 : 0;

ну я понял что не rest\

просто пытаюсь понять чем этот подход лучше

query это часть httpserverrequest

этот класс можно и с генераторами использовать, вроде

не в этом дело, имхо

Олег а есть идеи -- ну тупо может мысли какие нить есть

чтобы понять какая может быть тут логика

а в чём задача то?

и да почему то что я показал это не рест. Выглядит же похожу

да пока разобраться просто хочу. Думаю у своего сайта какой АПИ делать

для отдачи контента и взаимодействия с пользователями

https://ru.wikipedia.org/wiki/REST

пока у меня тупо ручная обработка

по сути rest не для человека

а для программ

https://github.com/rejectedsoftware/vibenews/blob/master/source/vibenews/admin.d#L93

здесь же рендерится html в ответ

значит пользователю передаётся не жуткий json или того хуже xml

а страница с красивыми css'ами

а рест это все дело не умеет? там только джейсон? Я статью читал много раз просто мне видимо не все очевидно

моё понимание rest'а в том, что это интерфейс взаимодействия программных компонентов через сеть

если ты в своей архитектуре хочешь сделать иначе, то тебе никто не мешает

ERROR: S client not available

путем перекидки джейсоном?

да

или xml

или soap

не важно

а рест это все дело не умеет? там только джейсон? Я статью читал много раз просто мне видимо не все очевидно

рест ничего не знает о том в каком виде отдается контент. Главное чтобы был stateless и именование ресурсов

есть 2 основных момента

вот, первый это stateless

ну а что мешает по рест html отдавать?

отренденный шаблон

второй это то что данные передаются в виде удобном для другого кода

можешь и html передавать, разницы нет

только тебе по логике на другой стороне нужно парсить этот html

и вопрос, зачем мешать rest и web?

в web пользователь логинится, видит разные красивости на странице, программе это не нужно, это лишнее время на разбор текста, json для неё читабельней

Верно, потому что html это то что рендерит браузер для человека. А через рест общается сервер с сервером, им трудно общаться с помощью html, гораздо удобнее json

rest подразумевает, что на сервере не хранится сессий

я чуть позже отвечу. щас от компа надо отойти

просто переосмысли эту идею)

я читал переписку и у меня возникло ощущение, что Дмитрий, возможно, неправильно понял, к чему относилось "не rest это") т.е. то, что генерит rest-генератор от vibe, вполне себе rest, неcмотря на то, что не гарантирует stateless

или это я не вник, и он ссылался на совершенно другой генератор?

я читал переписку и у меня возникло ощущение, что Дмитрий, возможно, неправильно понял, к чему относилось "не rest это") т.е. то, что генерит rest-генератор от vibe, вполне себе rest, неcмотря на то, что не гарантирует stateless

код vibenews/admin.d не является rest, и вообще не использует генератор (ни rest, ни web)

там всё руками прописывается

весь роутинг и разбор запросов

Dmitry Bubnenkov, [07.11.16 15:10] просто до этого я думал что рест надо так генерить: http://vibed.org/api/vibe.web.rest/registerRestInterface Oleg B, [07.11.16 15:11] так это не rest я об этом вот моменте переписки. И мне показалось, что Дмитрий сбился с толку

а, ну возможно

потому как в случае этой функйции вполне себе годный rest получается, на мой взгляд)

не спорю

но!

но stateless он не гарантирует)

тут возникал вопрос один, мы не нашли (да и не углублялись особо) решения

смысл в том, что для доступа к rest по нашей схеме нужен был токен