Ловим баги в шерсти кода, обсуждаем нововведения, реквестируем новые плюшки. Шатания выходят на совершенно новый уровень, сумеет ли Курисаба-тян пережить всю мощь костыльной синергии Хомуры, Рейму и 1.5 анонов? Скоро узнаем. Предыдущий >>32736
>>48378 Из плюсов то что в RPC одна точка входа и не нужно ничего проектировать как в api. У тебя просто набор методов. Это особенно удобно когда методов много. Но все же мне кажется в данном случае для нескольких вьюшек rpc не нужно и даже оверхед.
А для оп-пика обязательно надо было брать порнографию?
>>48357 > Скоро узнаем Вот прошлым вечером и узнали :D
>>48294 >JSON RPC Ок, надо будет посмотреть, что это за зверь такой. >>48299 >[{op_post:POST, answers:234, pic_answers:48, posts:[POST, POST, POST]}, {op_post:POST, answers:458, pic_answers:124, posts:[POST, POST, POST]}] Да, это будет нормально. >Если они на сервере хранятся как отдельные поля, то лучше отдавать отдельно Да, как отдельные. Ок. Там даже размер тамбнейла зачем-то есть. Могу и его отдавать. >>48304 >разве для пхп стандарт не lowerCamelCase для методов? Насколько я видел, PHP — смесь всего: и CamelCase, и lowerCamelCase, и snake_case. >>48309 И? >>48319 >Просто думал, что ты уже знаешь. Не, к сожалению, не проверял. >Интересно, зачем это было? Вот у >>48321 написано. И суть именно в том, чтобы делать его не hidden, а прятать с помощью стиля: ибо первое — более тривиальная вещь и пасётся большим числом ботов, чем второе. >Так можно было в настройках выбрать, задействовать gd или imagemagick. Да. Только последнего на сервере нет. >сервер БУДЕТ пытаться загрузить изображение, даже если его размер превышает всякие рамки здравого смысла. Но разве он не выделит поначалу для него необходимую память (при попытке чего для гигантского изображения он закономерно обломится)? >Например, поставить такой код: Но, конечно, да; раз уж getimagesize() была вызвана, то можно и проверить, заметного оверхеда не будет. >Почему видя png, курисаба делает предпросмотр в png, хоть это и куда больше обычных предпросмотров, а видя gif — делает gif, хоть это и выглядит откровенно убого? Честно? Не знаю. Так было. =) Возможно, чтобы полагаться в превьюшке на imagetype. Ну и, наверное, для того, чтобы фоточки жать как фоточки, а рисунки — как рисунки, а не шакально. Хотя на превьюшке это будет малозаметно. >Пока друг не понял, что это «CATALOG». Да-да. Стоп, а я разве это не вычистил?! Вот же ж... >что делать с loadbalancer'ом, но, присмотревшись, понял, что он безнадёжно сломан. И, при надобности, чинить его и так уже нужно весь. Я, если честно, могу только по названию предположить, для чего он нужен. И не проще ли его выпилить... или всё же пусть остаётся, а если надо будет — починим? >Но, объективно говоря, я не буду тебя бранить, если ты это не закоммитишь в продакшн. Проверку размеров — закоммичу, выпиливание создания каталожных тамбнейлов — тоже, а вот про gif/jpg/png... Тут вот какое дело: большинство тамбов, которые есть — того же типа, что и файл; поэтому либо надо их все конвертать (а я на подобное как-то раз убил целую ночь), либо как-то различать, где тамб jpg-шный, а где — нет. >>48326 >Заинтересовало также поле «MAX_FILE_SIZE». Вроде как оно использовалось для проверок при загрузке файла, которые стали не нужны после реализации js-отправки. >>48331 >они успеют еще 10 API сделать и новый движок, пока я хоть что-то смогу запилить. Отчего-то проиграл. >>48333 >И вся универсальность накрывается, всё равно будут отличия. Так всё дело-то как раз в том, что в целом разметка остаётся той же — и даже тянет за собой исторические вещи. Как, например, тепбе класс .unkfunc для спойлеров? >Не проще ли обойтись гетом с передачей параметров через URL? Как правильно говорит Рейму (>>48335), в строке GET передать можно только что-то небольшое — например, id борды или там номер поста. Список постов, например, — уже нет. >>48334 Лол. А у меня сегодня показывало -4 соединения к базе. Какой-то просто день негатива (в буквальном смысле, от negative — «отрицательный»). P.S. Если вдруг найдёшь причину — сообщи, ладно? >>48335 >Да, Json применять как затычку в каждую дырку — действительно выглядит глуповато. А почему не его? Универсальный механизм представления данных в виде строки, хорошо поддерживается как клентом (javascript), так и сервером (PHP). >>48336 >Единственная причина так делать — быть не такими как все, вот и всё. А какими бывают все? Я просто не знаю. Может, есть и другой велосипед, кроме JSON. >апи никогда не разрастётся до такого, что запрос не влезет в адресную строку Почему же? К примеру, передача массива из 50-100 номеров постов. В 255 символов это точно не впихнуть. >GET значит получить. Я хочу получить список тредов, получить список постов, получить какой-то пост. ...Получить содержимое 50 постов, которые появились в треде с последнего обновления, например (без придумывания костылей типа запроса получить_последние_посты_треда_с_данным_ОП-постом_пришедшие_с_такого_то_момента()). Да, не очень логично, да, сбивает кэширование. Но лучшего способа я не вижу. Впрочем, конечно, можно сделать так, чтобы запрос на получение можно было отправить как GET-ом, так и POST-ом, если надо. >>48353 >то придется предварительно энкодить файл хотя бы в base64. А это уже 33% к весу файла. Так через форму же файл так же отправляется, если я не ошибаюсь. >>48378 >Забавно, я в новый тред с дашачана отписаться не могу. Мда, жесть какая-то. >Как освобожусь, постараюсь разобраться, в чём дело. Да, постарайся, пожалуйста. >>48387 >Но все же мне кажется в данном случае для нескольких вьюшек rpc не нужно и даже оверхед. Да, пожалуй, так оно и есть. >>48410 >А для оп-пика обязательно надо было брать порнографию? Да, что-то меня тоже ОП-Хомочка смущает. Да, кстати, гоменнасай за сегодняшние пропадания Курисача. Тут вообще какое-то адище было. Ваша Хомура вот сейчас только оклемалась от битв с ведьмами, захватившими хостинг Курисача, лол. Во-первых, накрыло базу на сервере (и она не вставала, похоже, даже после ребута), во-вторых, число соединений к базе отчего-то было отрицательным, и в-третьих — я решил в процессе поиска проблем переключить версию PHP на ту, которая более лучше (то есть, седьмую), из-за чего оно поругалось немного на конструкторы классов — пришлось в срочном порядке дописывать, ибо переключение обратно отчего-то ввело сервер в странную ситуацию, когда пятый и седьмой PHP переключались с интервалом в несколько секунд, лол. Алсо, похоже, я нашел механизм, через который нас пытались завалить — это был никакой не модный 0day в mysqld, а банальный SQL injection, который можно было устроить в форме поиска (причём, совершенно дурацким способом). К счастью, я успел это поправить быстрее, чем злодей подобрал нужное количество скобочек и кавычек для классического Robert'); DROP TABLE Students; --. =) И есть подозрение, что вложенными запросами SELECT SLEEP(5) он базу и положил. И ведь только вчера, судя по кэшу гугла, нас обсуждали на тирече (и как раз во время обсуждения клауда зарегистрировала ненормальный пик трафика и посещений). Сбэкаплю-ка я базу на всякий случай, а то вдруг что...
[{op_post:POST, answers:234, pic_answers:48, posts:[POST, POST, POST]}, {op_post:POST, answers:458, pic_answers:124, posts:[POST, POST, POST]}]
getimagesize()
.unkfunc
Robert'); DROP TABLE Students; --
SELECT SLEEP(5)
>>48420 Хранить размер превью важно т.к до загрузки превью браузер ничего не знает о ее размере и страница будет прыгать.
Оп пост в респонзе лучше не выделять, а поместить в посты(потому что внезапно это пост). Так будет удобнее всем. Генерировать превьюшки лучше в jpeg и разве что для png модно оставить т.к альфаканал выглядит красиво. Его по идее можно даже детектить. Если сейчас менять то придется либо в шаблоне ставить условие пересоздавать все превьюшки, либо писать в базу тип превью. Не, я понимаю что быдлокодеры пишут как угодно, но в 2016 игнорировать соглашения и общепринятые стандарты это плохо. Кстати ж надеюсь тут PDO используется?
>>48333 >POST в виде JSON? Хорошо ли это? Не проще ли обойтись гетом с передачей параметров через URL? «get_posts_by_id» может передавать достаточно много информации, так что оно не влезет в URL. Тем более ответ-то все равно нужен JSON. >>48335 >Да, Json применять как затычку в каждую дырку — действительно выглядит глуповато. А какие есть еще оптимальные варианты для мобильных приложений? >>48336 >Полагаю, апи никогда не разрастётся до такого, что запрос не влезет в адресную строку, даже близко такого не будет. «get_posts_by_id». Уже. >>48353 >это не API, а RPC Я, наверное, чего-то не понимаю, но разве RPC — это не один из стандартов для реализации API? Одно другого не исключает же? >но клиенту придется работать с двумя ресурсами Да в общем-то с одним и тем же курисачем, просто рид будет через /json.php, а пост через /boards.php >>48420 >Да, это будет нормально. Тут анон ниже предлагает оп-пост не выделять, а просто ставить первым в список постов. Думаю, он прав, потому что в запросе отдельного треда у меня оп-пост тоже не выделяется, будет унификация. [{answers:234, pic_answers:48, posts:[POST, POST, POST, POST]}, {answers:458, pic_answers:124, posts:[POST, POST, POST, POST]}] >Там даже размер тамбнейла зачем-то есть. Давай, как thumbheight и thumbwidth. Мне кажется, оно вряд ли понадобится, но все-таки. >Отчего-то проиграл. Нет, серьезно, торопится некуда. Можно начать с функции «get_boards», поскольку она самая простая, а заодно станут видны трудности на пути, да и для тестов мне на ближайшее время хватит более чем. >>48428 >Оп пост в респонзе лучше не выделять, а поместить в посты Разницы, на самом деле, для клиента особой нету. Вопрос как будет удобнее на сервере реализовывать.
[{answers:234, pic_answers:48, posts:[POST, POST, POST, POST]}, {answers:458, pic_answers:124, posts:[POST, POST, POST, POST]}]
>>48429 Они предоставляют некий интерфейс, но в RPC ты вызываешь методы через одну точку входа. А сервисы в нем могут могут быть вообще никак не связаны. Про ресурсы это я в смысле что тут будет рпц, а там форма. Не очень кошерно.
>>48428 >Не, я понимаю что быдлокодеры пишут как угодно, но в 2016 игнорировать соглашения и общепринятые стандарты это плохо. Когда речь касается движка 2007 года, в который напихали костылей по самую глотку, то о каких соглашениях может идти речь?
>>48440 Ты пишешь новый код, у которого общего со старым разве что БД. Логично бы начать писать правильно т.к это по сути новый проект(и я предлагаю так и сделать. Будет полезно почитать http://www.phptherightway.com/
>>48452 Я просто мимошел, если что. >у которого общего со старым разве что БД В таком случае да. Я говорил в конексте интеграции каких-то фич в сам движок.
>>48453 Я им уже много раз предлагал не насиловать труп и начать потихоньку переписывать важные компоненты. Или дорабатывать один из современных движков. Сами фичи да, хуево пилить что-то годное, когда основа херовая лапша с «собачками».
>>48420 > Так всё дело-то как раз в том, что в целом разметка остаётся той же — и даже тянет за собой исторические вещи. Вот с чего ты взял вообще? Какую-то совместимость могут сохранять, какую-то — нет. Нельзя быть в этом уверенным, у веб-разработчиков разные требования к совместимости, большинство, я думаю, просто забивает, и вполне справедливо: кукла работает — и хватит на этом. > Как, например, тепбе класс .unkfunc для спойлеров? Это частный пример, в общем-то, ничего не доказывающий. И не для спойлеров, а для цитат. Кстати, скорее всего это используется для универсальности стилей, а не для парсинга. > А почему не его? Универсальный механизм представления данных в виде строки, хорошо поддерживается как клентом (javascript), так и сервером (PHP). > А какими бывают все? Я просто не знаю. Может, есть и другой велосипед, кроме JSON. Универсальный механизм — это application/x-www-form-urlencoded или multipart/form-data, именно таким образом браузер кодирует формы. Через javascript можно передавать любые данные, включая JSON, но стоит 10 раз подумать перед этим. > Почему же? К примеру, передача массива из 50-100 номеров постов. В 255 символов это точно не впихнуть. Зачем ты будешь передавать массив из 50-100 номеров постов? Можно, конечно, сейчас навыдумывать кучу бессмысленных запросов, которые не будут влезать в адресную строку, но давай исходить из потребностей: где могут понадобиться такие длинные запросы? В крайнем случае, если очень нужно, — можно допустить работу как через GET, так и через POST. > ...Получить содержимое 50 постов, которые появились в треде с последнего обновления, например (без придумывания костылей типа запроса получить_последние_посты_треда_с_данным_ОП-постом_пришедшие_с_такого_то_момента()). А номера этих 50 постов ты откуда будешь узнавать? Будет запрос номеров постов в треде, сравнение с текущими, а затем вторым запросом получение нужных постов? Звучит дико. Кстати, то, о чём ты сказал, — не костыль. Так работают все борды, имеющие внизу страницы кнопку «Получить новые посты». Либо же грузят целый тред, но это совсем другая история. > Так через форму же файл так же отправляется, если я не ошибаюсь. Если используется multipart/form-data, то файл в чистом виде отправляется. А он используется. > Да, постарайся, пожалуйста. Я что-то вчера очень утомился, сегодня вечером посмотрю.
>>48357 Хомура окончательно увиабушил в закат.
Не знаю, писали уже или нет, но если открыть последние 50 постов в треде, а потом жмакнуть кнопочку «Получить новые посты», то магия работает как-то не так. >>48529 В смысле?
>>48430 >Не очень кошерно. Если все делать через JSON, то >>48353 >то придется предварительно энкодить файл хотя бы в base64. А это уже 33% к весу файла Это еще более некошерно. >>48519 >Через javascript можно передавать любые данные, включая JSON, но стоит 10 раз подумать перед этим. Какой такой javascript? Приложение мое будет на QML + Python, а модули дашчана или Микучана не знаю, на чем пишутся, но не на JS. >Будет запрос номеров постов в треде, сравнение с текущими, а затем вторым запросом получение нужных постов? Звучит дико. Почему же? Преимущества: 1) Маленькая нагрузка на сервер — отдавать список постов в треде или посты по id нагружает мало. В отличие от той ситуации, когда серверу приходится вычислять, а какие посты клиенту отдавать, а какие у него уже есть. Причем кэширование все равно сбито будет в любом случае, ибо у каждого клиента свои наборы требуемых им постов. 2) Удаленные посты — клиент будет видеть, какие посты удалены, по разнице всписках постов. Минусы: 1) При обновлении 2 запроса вместо одного — один за списком постов, и второй, чтобы получить новые посты.
>>48427 >Хранить размер превью важно т.к до загрузки превью браузер ничего не знает о ее размере и страница будет прыгать. Ок, ладно, тогда вопрос — надо ли его отдавать клиенту? >>48428 >Генерировать превьюшки лучше в jpeg и разве что для png модно оставить т.к альфаканал выглядит красиво. А в теории, в gif можно делать анимированные превьюшки (и такой реквест уже был). Так что, кажется, смысла делать превью исключительно в jpg нет. >Если сейчас менять то придется либо в шаблоне ставить условие пересоздавать все превьюшки, либо писать в базу тип превью. Ага, первое — долго, а второе — костыль. >Не, я понимаю что быдлокодеры пишут как угодно, но в 2016 игнорировать соглашения и общепринятые стандарты это плохо. Если ты можешь — напиши, в конце концов. Я вообще до начала копаний с курисабой с веб-разработкой был знаком весьма поверхностно. >Кстати ж надеюсь тут PDO используется? ADO. >>48429 >Тут анон ниже предлагает оп-пост не выделять, а просто ставить первым в список постов. Да, хорошо. >Давай, как thumbheight и thumbwidth. Мне кажется, оно вряд ли понадобится, но все-таки. Ладно, не жалко, пусть будет. >>48456 >Я им уже много раз предлагал не насиловать труп и начать потихоньку переписывать важные компоненты. А я много раз говорил: чтобы полноценно это сделать, времени лично у меня не хватает. Это надо брать, не знаю, отпуск на месяц, садиться и переписывать это всё. И то у меня именно опыта разработки под веб практически нет (считай, серьёзно я его начал как раз с курисабы). Вчерашняя инъекция в поле поиска тому подтверждение. Давайте поможем Хомуре переписать курисабу Если кто хочет, может написать свой движок, но главное — чтобы он поддерживал все используемые фичи курисабы и при этом позволял если не использование той же самой базы, то хотя бы несложную конвертацию формата базы туда и сюда. >>48519 >Какую-то совместимость могут сохранять, какую-то — нет. >кукла работает — и хватит на этом. Но ведь это уже значит, что базовая совместимость есть. А именно она нужна для клиентов. >Это частный пример, в общем-то, ничего не доказывающий. Правильно, это пример, как раз показывающий то, что большинство старается сохранять совместимость. >И не для спойлеров, а для цитат. Да, пардон. >Кстати, скорее всего это используется для универсальности стилей, а не для парсинга. Но ведь для универсальности же. >Универсальный механизм — это application/x-www-form-urlencoded или multipart/form-data, именно таким образом браузер кодирует формы. Его создание в javascript на порядок сложнее. Сможешь ли ты одной строчкой упаковать в один из этих форматов, к примеру, массив объектов, в том числе содержащих массивы? К примеру, страница доски как раз собой такое и представляет. Конечно, эта страница приходит с сервера, а не уходит на него, но я про то, что проще, когда и туда и сюда идут данные в одном и том же формате. >В крайнем случае, если очень нужно, — можно допустить работу как через GET, так и через POST. Ну я про это и говорю. Так и сделаю, и кто хочет — может работать через GET, кто хочет — через POST. >Будет запрос номеров постов в треде, сравнение с текущими, а затем вторым запросом получение нужных постов? Почему нет? >Кстати, то, о чём ты сказал, — не костыль. Так работают все борды, имеющие внизу страницы кнопку «Получить новые посты». Это просто один метод на совершенно конкретный случай и больше ни на какой. Т.е., никакой реюзабельности и расширяемости. Мне, всё же, больше нравится unix-way, когда есть куча простых инструментов, которые можно комбинировать и получать то, что тебе надо. >Если используется multipart/form-data, то файл в чистом виде отправляется. Хм, всю жизнь думал, что он там точно так же в base64. Ладно, мб я и неправ. >>48529 Нэ? Если что, перекат делал не я >>48613 Да, знаю. В процессе фикса. Кстати, выкачу сюда последние фиксы: — длинные скрипты в админке вызываются два раза (minor) (hard) — DELAYED (таких скриптов уже нет; а вообще проблема сервера, если решим переехать — починим) — есть проблемы с символами utf8mb4 (minor) (hard) — DELAYED (похоже, проблема сервера, если решим переехать — починим) — (NEW) превьюшки вембок генерить (minor) (hard) — DELAYED (проблема сервера, если решим переехать — починим) — (NEW) сделать https от клауды до Курисача (minor) (easy) — DELAYED (проблема сервера, если решим переехать — починим) — если нет куков, отдаются просроченные страницы (normal) (medium) — NEED INFO (теперь страницы генерятся динамикой; проверяйте, не починилось?) — при некоторых условиях пропадает трипкод и имя (minor) (medium) — NEED INFO (не могу воспроизвести; нужна инструкция по воспроизведению бага) — (NEW) превьюшки генерить только в формате jpg (minor) (medium) — NEED INFO (надо взвесить все «за» и «против») — (NEW) read.php сбивает обновление треда (тред перезагрузается и дописывается в конец) (major) (hard) — DONE — (NEW) кукла — request_uri обрезать по знаку вопроса (major) (easy) — DONE — (NEW) SQL-injection в форме поиска (major) (easy) — DONE — включенное автообновление жрёт очень много ресурсов (normal) (hard) — DONE (правда, оказалось, из-за переписывания innerHTML) — хайлайт сбивает автообновление (normal) (medium) — DONE (обновление переписано, теперь должно работать) — автообновление: счетчик тикает, но посты не обновляются (normal) (medium) — DONE (обновление переписано, теперь должно работать) — (NEW) после редактирования постов — два таймера одновременно (normal) (easy) — DONE — (NEW) при обновлении не альтерится карта ответов ОП-поста (normal) (easy) — DONE — (NEW) перейти на PHP 7 (normal) (easy) — DONE — оптимизация подгрузки постов (json) (minor) (hard) — DONE — сделать в шаблоне капчу только если на доске капча включена (minor) (easy) — CANCELLED (не стоит, а то мамкины вайпиры сразу набигают) — word-wrap не работает (minor) (easy) — DONE — кат не помещается в пост с картинкой правильно (minor) (easy) — DONE — (NEW) шрифты брать по https (minor) (easy) — DONE — (NEW) номер добавляемых постов при автообновлении промахивается на 1 (minor) (easy) — DONE — (NEW) «нет новых постов» — убрать при редактировании поста (minor) (easy) — DONE — (NEW) говорить, что в хроме кукла не обнаружена (minor) (easy) — DONE — (NEW) отключать фичи, несовместимые с куклой при первом детекте (minor) (easy) — DONE — (NEW) заголовок в поиске постов через read.php и read2.php (minor) (easy) — DONE — (NEW) в стиле tuvik, claire, cdark, claire.advance черный шрифт во фрейме (minor) (easy) — DONE — видео+картинка (major) (hard) — (NEW) проверка размеров заливаемых пикч (major) (easy) — сделать отправку по Ctrl+Enter настраиваемой (normal) (hard) — без капчи посты с куклы отправляются два раза (normal) (medium) — скрытие постов по имени, тексту поста (minor) (hard) — сделать переключение английского и русского интерфейса (minor) (hard) — (NEW) делать API для Суигинто (minor) (hard) — откуда-то лезет скроллбар и почему-то превьюшка вылезает за край (minor) (medium) — картинки, похоже, разворачиваются больше, чем надо (minor) (medium) — спойлеры картинок (minor) (medium) — cделать отдельно однопоток постов как на хорочане или как на хайбане (minor) (medium) — анимированные превьюшки, выключенные по дефолту (minor) (medium) — сделать улучшенный хеш для бана, чтобы он высчитывался без последних 2-5-10 байт (minor) (medium) — vimeo не отображает превьюшки видео (minor) (medium) — фрейм колбасит (см. пост 42066) (minor) (medium) — чтобы был и диалог открытия и превью по клику на зоне «перетащи файл сюда» (minor) (medium) — скрытие отдельных постов, навроде кнопочки скрытия треда, только для постов (minor) (medium) — сделать, чтобы предпросмотр закрывался при отведении мышки (minor) (medium) — разворачивание поста на предпросмотре со страницы борд (см. пост 46341) (minor) (medium) — (NEW) Из превьюшек удаляются карты ответов при автообновлении (minor) (medium) — (REOPENED) «https://kurisa.ch/sg» переводит на «http://kurisa.ch/sg/» (minor) (hard) — ускорить статистику в админке (minor) (easy) — предпросмотр поста не закрывать при клике по кату (minor) (easy) — предпросмотр поста при правке глючит (minor) (easy) — (NEW) Разворот поста и всплывание меняет номер на 1 (minor) (easy) — (NEW) автообновление косячит в режиме «последние 50 постов» и «первые 100 постов» (minor) (easy) — (NEW) шрифты захостить локально (minor) (easy) — (NEW) выпилить создание каталожных тамбнейлов (minor) (easy)
Микуоверчани н-не отправляет посты и пишет ошибку 301.
>>48635 Размеры не будут лишними, хотя зависит от типа клиента, но отдавать их определенно надо. Анимированные гифки на превью? Кто-то знает толк. Еще и вес соответствующий. Я б написал и уже пишу потихоньку, но дело в том что пишу на go. А это уже сразу минус хостинг, здравствуй вас. По поводу инъекции. Параметры не были забинжены? >>48646 Приду домой пофикшу, или скорее всего завтра.
>>48630 > Почему же? Потому что можно сделать один запрос в стиле «получить все посты, чей номер больше X», где X — номер последнего поста в треде. Получишь тот же результат, только на порядок проще. >>48635 > Но ведь это уже значит, что базовая совместимость есть. А именно она нужна для клиентов. Откуда ты знаешь, какая совместимость есть? Откуда ты знаешь, что совместимость — базовая, а не почти нулевая? > Правильно, это пример, как раз показывающий то, что большинство старается сохранять совместимость. Нет, он этого не показывает. На самом деле, он вообще ничего не показывает. > Его создание в javascript на порядок сложнее. Я тебе по секрету скажу, на чистом javascript всё достаточно сложно. А вот с jquery — в одну строчку. > в том числе содержащих массивы Опять же, давай конкретно, где такое нужно, а не высасывать из пальца. > когда и туда и сюда идут данные в одном и том же формате В общем-то нет. Веб так не работает. > Почему нет? Излишняя сложность ради сложности. > Это просто один метод на совершенно конкретный случай и больше ни на какой. Т.е., никакой реюзабельности и расширяемости. А больше случаев нет, некуда расширять. К тому же ты жертвуешь многим: 1. Нужно 2 запроса к серверу. 2. Более сложный запрос к бд. Не знаю, как сильно второе повлияет на производительность, но селект будет гораздо сложнее. Если раньше ты просто делал select ... where id > 1488, то теперь это будет where id in (1489, 1493, ...) Нашёл код дашачана для курисачика, буду разбираться с проблемой с капчей и минусами в избранном.
>>48674 > Нашёл код дашачана для курисачика, буду разбираться с проблемой с капчей и минусами в избранном. Я, кажется, понял в чём дело. Дело в запросе последних 50 постов в треде (который XXXXX+50.html), если постов меньше, пишет «Слишком мало постов в треде» с кодом 200. А раньше, когда были статические страницы, сервер отдавал 404 т.к. не находил такого файла. Надо сделать, чтобы 404 отдавал как и раньше. Или, как вариант, чтобы выдавал имеющиеся посты, даже если их меньше 50.
И ещё баг нашёл. Запросы вида https://kurisa.ch/read.php?b=sg&t=48357&p=48674&single отдают пост с номером [1]. Если с доски развернуть пост, то его номер заменяется на [1], что не очень красиво. Запрос можно не модифицировать, а вот скриптом сохранить и восстановить номер — можно. Но это мелочь уже, конечно.
А поиск теперь вообще не работает что ли?
>>48688 Что-то лол. И правда не работает. Изи способ избавиться от инъекций. Где-то я такое уже видел.
«Опаньки.» Вдруг обнаружил, что при некоторых обстоятельствах при предпросмотре с другого треда может отвалиться карта ответов. Пока причины неизвестны. Но баг неплохо воспроизводится, если «погулять» по переходам цитат на примере этого поста > >>43032 Если в нём навести на цитату (я испытывал на >>/sg/42824 ), от неё ещё цитату, (We need to go deeper!), а там уже беспорядочно открывать/закрывать вложенные «наводки по цитатам», пока не обнаруживаем, что все карты ответов на всплывающих постах отвалились. Не сильно мажорный баг, я бы сказал. Но, возможно, сможет что-то сказать о внутренностях клиента. Может, это даже поможет что-то решить. На самом деле не верю.
>>48635 >А в теории, в gif можно делать анимированные превьюшки (и такой реквест уже был). Пожалуйста, не надо. Нужно просмотреть гифку — в полном её формате, и по клику. Автовоспроизведение сделает калейдоскоп вместо страницы. А нужно текст читать. >Я вообще до начала копаний с курисабой с веб-разработкой был знаком весьма поверхностно. Ого, даже так. Молодец, что запилил столько всего. >Это надо брать, не знаю, отпуск на месяц, садиться и переписывать это всё. Сейчас будет звучать речь как саботаж, но: лучше распланируй отпуск на что-то здоровское. Такой вот короткий совет. Походы, встречи со старыми друзьями (если они друзья), поездка в горы/море. Курисач пилить нужно. Но и самому жить тоже. Твой темп разработки, мне кажется, и так очень высок. Да, «придём к коммунизму» так мы не совсем скоро. Но и сейчас уже довольно хорошо. >Так и сделаю, и кто хочет — может работать через GET, кто хочет — через POST. Сервером это делается в пару строк. Да и уже сколько лет подряд в PHP есть унифицированный «$_REQUEST». Мне кажется, тут даже думать не нужно. >перейти на PHP 7 А, так вот что это было. Сервер обновили.>>48674 >Я тебе по секрету скажу, на чистом javascript всё достаточно сложно. А вот с jquery — в одну строчку. А ты так же быстро и в одну строчку успел приравнять своё мнение к потолку подземелья. Ну как так. >В общем-то нет. Веб так не работает. И опять-снова. Да какая разница, как он работает обычно или у кого-то там? >Нужно 2 запроса к серверу. Это в первую очередь. Все адекватные люди стараются минимизировать количество установок соединений, т.к. это накладно. А особенно на https.>>48695 >Что-то лол. И правда не работает. А, так вот чего он мне 404 выдал. Я думал, он результат не нешёл.
>>48718 > Я думал, он результат не нешёл. Так он на любой запрос выдаёт, что ничего не найдено.
>>48711 На самом деле, да. Сталкивалась с таким багом уже не раз. Немножко раздражает
>>48718 > А ты так же быстро и в одну строчку успел приравнять своё мнение к потолку подземелья. Ну как так. Это не моё мнение. Обычный ajax на чистом javascript делается через xhr, да ещё данные кодировать надо вручную. А на jquery — $.post. > Да какая разница, как он работает обычно или у кого-то там? Вебу много лет, программированию — тем более. Если ты что-то делаешь не как обычно и как принято, скорее всего ты делаешь говно. Надо обосновывать выбор, а не делать как хочется. Даже если ты думаешь, что твой велосипед получится красивым, не факт, что это реально будет так. > Все адекватные люди стараются минимизировать количество установок соединений, т.к. это накладно. А особенно на https. 2 последовательных запроса, скорее всего, выполнятся на одном соединении.
>>48674 >можно сделать один запрос в стиле «получить все посты, чей номер больше X», где X — номер последнего поста в треде А как же удаленные посты? >Если раньше ты просто делал select ... where id > 1488, то теперь это будет where id in (1489, 1493, ...) Ну, во-первых, select ... where id > 1488 and op_post = 1137; ты забыл второе условие. А во-вторых, стоит проверить скорость выполнения и того и другого запроса, мне интересно, что быстрее.
>>48752 > А как же удаленные посты? Это не столь важная информация, я бы даже сказал наоборот, полезно, что посты не будут удаляться при автообновлении. Но если очень нужно — можно первым запросом получить посты после Х, а вторым запросом — все номера постов, после чего удалить на странице посты не из списка. Это гораздо лучше, чем отбирать номера постов. > ты забыл второе условие. Я хотел акцентировать внимание на совсем другое. Если уйти в строгости, то ты ещё и board == 'sg' and not deleted забыла а может что-то ещё, ведь движок сильно изменился, но дело-то не в этом. > А во-вторых, стоит проверить скорость выполнения и того и другого запроса, мне интересно, что быстрее. Пускай Хомура придёт, займётся, тоже интересно.
>>48751 >Обычный ajax на чистом javascript делается через xhr, да ещё данные кодировать надо вручную. А на jquery — $.post. formdata уже давно есть. Пользуйтесь им. А насчет jquery, уже много где она не нужна. На борде точно. >>48752 >А как же удаленные посты? В кусабе посты только помечаются как удаленные, аля deleted_at, можно их тоже запрашивать(хотя бы с пустой моделью). Суть ведь чтобы пометить их как удаленные, а не убрать из дерева. Да, потестил микучан из гита — работает. Просто соберите из репы или ждите релиза мику. Могу сделать билд если кому надо.
Хомура-чан, поиск теперь из принципа работать не будет?
>>48755 >полезно, что посты не будут удаляться при автообновлении А они и не будут — просто в клиенте помечать их как удаленные. Как куклоскрипт. >можно первым запросом получить посты после Х, а вторым запросом — все номера постов И чем же это лучше-то? Тут вообще получается два запроса. >board == 'sg' Неужели таблица одна на все доски? >>48802 >хотя бы с пустой моделью Извини, не поняла. Что за модель? >Суть ведь чтобы пометить их как удаленные Это уже вопрос клиентского приложения, что с ними делать. >>48806 Не волнуйся, у Хомуры и так много дел, когда освободится — починит. Не надо торопить.
На самом деле QML довольно годная штука, хоть я и ловлю с нее тонны боли, когда наступаю на грабли из-за непонимания. Нет, приложение не делает запрос, там пока вручную сделанная «заглушка».
>>48809 > И чем же это лучше-то? Тут вообще получается два запроса. В исходном варианте их тоже два. Причём запрос списка постов неоправданно сложный, в отличии от моего варианта.
>>48646 Ок, записал, спасибо, Ханако. >>48671 >Параметры не были забинжены? Ну я забыл обернуть запрос в $tc_db->qstr();. >Приду домой пофикшу, или скорее всего завтра. О, это было бы отлично. Хотя бы узнать причину. >>48674 >Получишь тот же результат, только на порядок проще. Но менее универсально. Что, например, если клиент захочет грузить тред не целиком, а только видимую часть? В любом случае, расширить потом можно. Главное — не закладывать сейчас нерасширяемые решения. >Откуда ты знаешь, какая совместимость есть? Откуда ты знаешь, что совместимость — базовая, а не почти нулевая? Если её достаточно, чтобы сторонный софт (кукла, мобильные клиенты) понимали пришедшие им данные — значит, она уже достаточная (в части чтения разметки, я имею в виду). >Нет, он этого не показывает. На самом деле, он вообще ничего не показывает. Ну, я не знаю, как на такое отвечать. Есть мнение, что мы просто не понимаем друг друга. >А вот с jquery — в одну строчку. Show me the magic! По запросу «jquery object to form data» нашел только про обратное преобразование. >Опять же, давай конкретно, где такое нужно, а не высасывать из пальца. Вот я просто тебе скажу такую вещь. Я часто на работе, когда делаю очередную материнку или модуль, стараюсь запилить на них побольше возможностей. Поставить все возможные разъёмы (которые не нужны на данном этапе — просто не покупать и не запаивать), вывести побольше тестпоинтов, сделать хороший запас по питанию, большие диапазоны регулировок, поставить управляемые по PMBus источники и всё такое. И уже не один раз получалось так: 1. Я запиливаю функционал в плату 2. Начальник говорит: чёт много всего, выпили %фичанейм% 3. Я говорю «угу» и не выпиливаю 4. Плата отправляется в производство, на неё делают КД, получают литеру, всё такое 5. Потом звонит другой начальник и говорит: «слушай, а %фичанейм% в твоей плате нет, да? Черт, придется заново разрабатывать похожую плату» 6. Я говорю: «кухихи, нет, есть, я её не выпилил» 7. Другой начальник говорит «о, круто!» и мы имеем новый комплекс с нужной функциональностью через 2 месяца, а не через полгода. 8. ????? 9. PROFIT!! Поэтому так: я тебе не скажу на 100%, где точно будет использоваться такой функционал; может, не будет вообще, а может, наоборот, пригодится. Придумывать примеры применения можно сколько угодно, и мы не угадаем, какой точно будет и будет ли вообще. Но отказываться от возможности запилить функционал, который может потребоваться, я не хочу. >В общем-то нет. Веб так не работает. Расшифруй, пожалуйста. Чем это плохо? > Почему нет? Излишняя сложность ради сложности. > Это просто один метод на совершенно конкретный случай и больше ни на какой. Т.е., никакой реюзабельности и расширяемости. >Нужно 2 запроса к серверу. Отлично, можно запилить два запроса. Настраиваемый (для двухзапросной схемы) и ненастраиваемый (для однозапросной). Проблем в этом нет. >Если раньше ты просто делал select ... where id > 1488, то теперь это будет where id in (1489, 1493, ...) Да, если есть индекс по id (а он есть), то запрос со сравнением выполнился бы быстрее. Однако, там всё равно есть условие IS_DELETED = 0, поэтому ему в любом случае придётся проходить все выбранные строчки. >Нашёл код дашачана для курисачика, буду разбираться с проблемой с капчей и минусами в избранном. О, спасибо, будет хорошо, если удастся накопать причину. >>48678 >Надо сделать, чтобы 404 отдавал как и раньше. Или, как вариант, чтобы выдавал имеющиеся посты, даже если их меньше 50. Хорошо. Как будет лучше? >>48679 Уже есть в списке. Буду править. >>48688 >>48695 >>48806 >>48718 >>48720 >>48806 Упс! Да, чёт поиск сломался. Скоро поправлю, а пока просто оборачивайте то, что ищете, в значки процента, т.е. теперь вместо слово надо писать %слово%. >>48711 Тоже есть в списке, и я даже примерно знаю, из-за чего это. Тоже буду править. >>48718 >Автовоспроизведение сделает калейдоскоп вместо страницы. Да, ты прав, и я тоже так считаю, поэтому у меня специально написано: «выключенные по дефолту». >лучше распланируй отпуск на что-то здоровское. Ну само собой, говоря, что «надо так делать», я не подразумевал, что я действительно так буду делать, кухихи. В отпуске я лучше школьников электронике поучу в ЛМШ и просто отлично проведу с ними время, лол, чем буду сидеть переписывать курисабу простите меня, дорогие курисачане же. =) Но спасибо за заботу, Рейму. =) >Сервером это делается в пару строк. Да и уже сколько лет подряд в PHP есть унифицированный «$_REQUEST». Вот и я о том же. Ладно бы это было сложно, но ведь есть уже предназначенный именно для этого метод. >Все адекватные люди стараются минимизировать количество установок соединений, т.к. это накладно. А особенно на https. Ну тут два запроса — рациональная, имхо, цена гибкости. Можно сделать и однозапросную схему — не проблема же. >>48751 >да ещё данные кодировать надо вручную. Разве в FormData надо что-то кодировать? >Если ты что-то делаешь не как обычно и как принято, скорее всего ты делаешь говно. Пример: много ли ресурсов используют PUT и DELETE для добавления или удаления чего-нибудь — вместо типичного «POST на любую модификацию»? >Надо обосновывать выбор, а не делать как хочется. Я ж, вроде, обосновал. >>48755 >полезно, что посты не будут удаляться при автообновлении. Не называние ли это бага фичей? >Но если очень нужно — можно первым запросом получить посты после Х, а вторым запросом — все номера постов, после чего удалить на странице посты не из списка. Это гораздо лучше, чем отбирать номера постов. Всё равно два запроса, но такой вариант гораздо костыльнее. И всё ради чего? Чтобы не юзать POST? >Пускай Хомура придёт, займётся, тоже интересно. На нашем объёме данных оба запроса будут выполняться исчезающе малое количество времени. >>48809 >Неужели таблица одна на все доски? Конечно, одна, ибо одна структура данных. >>48814 >Причём запрос списка постов неоправданно сложный Как раз-таки нет. Ты перекладываешь сложность на клиент, хотя «выдать посты по списку» — вполне логичная серверная задача, в отличие от костыльного клиентского аналога «запросить всё, а потом вычленять оттуда то, что нужно».
$tc_db->qstr();
IS_DELETED = 0
слово
%слово%
Хомушка, Вам нинадоело бырократией занимацца? Тем более, што это лжа фсё, ага. Сколько небыло просьб в этой канцелярии, а картинку с видевой так и ничиво же, например.
Картинка с видевой не нужна. Пост будет выглядеть коряво. Я категорически против.
>>48818 Да. Нужна возможность прикрепления 5 картинок и видео. Будет в самый раз.
>>48818 Ссылка с раскрыть прям в посте даж, как, например у Юлички и на Двощах? Штож корявого-то, глупый?
>>48821 Завались, жирный.
>>48824 Я серьёзно. Одной пикчи мало.
>>48815 > Но менее универсально. Что, например, если клиент захочет грузить тред не целиком, а только видимую часть? Какую такую видимую часть? > В любом случае, расширить потом можно. Главное — не закладывать сейчас нерасширяемые решения. Можно просто потом добавить запрос на получение нужных постов параллельно к запросу на получение после определённого номера, хуже не станет. И, я уверен, это «потом» уже никогда не наступит или просто нигде не понадобится. > Если её достаточно, чтобы сторонный софт (кукла, мобильные клиенты) понимали пришедшие им данные — значит, она уже достаточная (в части чтения разметки, я имею в виду). Когда вы только ввели отображение номеров постов (в квадратных скобках), вы прописали ему класс postername. Дашачан из-за этого вместо имён постов показывал эти самые числа. Я тогда сообщил об этом разработчику, чтобы он исправил, но, тем не менее, такая небольшая оплошность — и уже что-то перестаёт работать как надо. Или, если помнишь, была проблема, когда ты ввёл новую карту ответов и вынес её в текст поста. Я тогда громко ругался и просил убрать их наружу, иначе эти ответы отображались как текст сообщения. Достаточная совместимость — миф: никогда не угадаешь, где можно накосячить. Не верю я в твои универсальные парсеры для каждого движка. > Ну, я не знаю, как на такое отвечать. Не обязательно отвечать. Во-первых, твой пример сохраняет совместимость для стилей, а не для парсеров, а во-вторых это единичный случай. Нужно доказательство всеобщности, а не существования, понимаешь? > Show me the magic! $.post. Передёшь в него JS объект — он сам из него формирует данные. > Но отказываться от возможности запилить функционал, который может потребоваться, я не хочу. Ради этого ты собираешься вводить свои велосипеды вопреки здравому смыслу. Можешь пофантазировать ещё дальше и тебе уже JSON не будет хватать. За всю жизнь до этого я не встречал сайтов, которые передают массив в массиве и которым вообще такое необходимо. Не надо совсем уж ерунды придумывать. > Расшифруй, пожалуйста. Чем это плохо? В вебе ты делаешь запрос, даже не обязательно пост, а в ответ ты можешь получить текст, картинку, аудио, видео, и т.д. Нет никакой необходимости формат входных и выходных данных делать идентичным, это абсолютно лишнее. > Отлично, можно запилить два запроса. Настраиваемый (для двухзапросной схемы) и ненастраиваемый (для однозапросной). Проблем в этом нет. Проблема в том, что ты плодишь сущности. Даже в двухзапросной системе нет необходимости в настраиваемом запросе. > Хорошо. Как будет лучше? Если сделать как раньше (404), то точно всё будет работать. Если же отдавать посты всегда, то я уже не уверен. Лучше всё таки первый вариант. > Разве в FormData надо что-то кодировать? Любой пост-запрос с содержимым надо во что-то кодировать. Ты строку в send передаёшь, а эту строку надо сформировать так или иначе. > Пример: много ли ресурсов используют PUT и DELETE для добавления или удаления чего-нибудь — вместо типичного «POST на любую модификацию»? Много. Не понимаю, к чему это. > Всё равно два запроса, но такой вариант гораздо костыльнее. И всё ради чего? Чтобы не юзать POST? Моя схема: 1. Запросить все номера постов. 2. Убрать удалённые посты. 3. Запросить новые посты после последнего поста. Твоя схема: 1. Запросить все номера постов. 2. Убрать удалённые посты. 3. Запросить все посты, которых нет на странице и есть в списке постов из первого запроса. Тебе как на клиенте, так и на сервере придётся выполнить больше разных вычислений. Надо как сформировать массив номеров новых постов, так и SQL-запрос с этим самым where id in (...). В моём же случае вообще ничего делать не надо. И ты ещё мой вариант костылём называешь? > Я ж, вроде, обосновал. «Может быть понадобится» — не обоснование.
>>48815 >И уже не один раз получалось так Ну и дела. Это же хардварь, и за каждую фичу нужно платить покупкой деталей. (Или ты оставляешь площадки?) Кстати, тут же вопрос: SPI может потянуть 10Мбит/сек на коротких дистанциях? >Ну тут два запроса — рациональная, имхо, цена гибкости. Можно сделать и однозапросную схему — не проблема же. Ну можно записывать историю последних изменений. Автообновление, всё же, штука активная. Да и работаем уже с динамикой-динамикой. >Пример: много ли ресурсов используют PUT и DELETE для добавления или удаления чего-нибудь — вместо типичного «POST на любую модификацию»? Да уж, ну и пример. Я бы не стал полагаться на них уже не только из сомнений в поддержке клиентами, так даже из сомнений поддержки сервером. Эта модель просто умерла в какое-то время. >Не называние ли это бага фичей? Нет, Хомура. Если бы я писал клиент, обязательно бы оставлял удалённые посты. Потому, что клиент уже по праву получил эту информацию. А потом по команде сервера должен удалять то, что пользователь желал бы прочесть. Неправильно это. Ладно ещё, если сервер просто не прислал. Тогда и говорить нечего. Но вот так действовать.. это уже неправильный клиент получается.
>>48832 >Какую такую видимую часть? Предположу, что имелась ввиду загрузка только малой части треда с последующей автоподгрузкой при надобности. >Достаточная совместимость — миф: никогда не угадаешь, где можно накосячить. Да, это очень глупо, когда каждый для себя определил границы API. Было бы куда лучше, если бы все цеплялись за одни и те же ключевые части. Но и не так много проектов работает с курисабой. Вот конкретно их функционирование и нужно поддерживать. >Ради этого ты собираешься вводить свои велосипеды вопреки здравому смыслу. Какие велосипеды? Что ты несёшь? Мы вообще-то новый движок пилим. >За всю жизнь до этого я не встречал сайтов, которые передают массив в массиве и которым вообще такое необходимо. Это да. >1. Запросить все номера постов. 2. Убрать удалённые посты. 3. Запросить новые посты после последнего поста. Твоя схема: 1. Запросить все номера постов. 2. Убрать удалённые посты. 3. Запросить все посты, которых нет на странице и есть в списке постов из первого запроса. А я вообще сижу и не понимаю, почему бы серверу не вести историю. Так он бы сам мог ответить на вопрос, что нужно клиенту. Там эту историю-то на больше 5 изменений за раз едва ли когда потребуется читать. Обновления же каждые 20 сек. Зато пересылаются все номера постов. Кстати, твой вариант был предыдущим. Мы так хорошо полетели на удалённых постах. Ну хорошо, тогда нужно было реализовать всё аккуратней, и на этом всё. Сейчас же на каждое обновление пересылается данных массив, что даже GET не поместится. Да и, объективно говоря, карта ответов из других тредов под вопросом. С историей последних изменений треда полегче будет ничего не упустить.
>>48817 У меня все ходы записаны, будет тебе картинка с видевой, это наступит скоро, надо только подождать. =) Ладно, постараюсь сделать побыстрей, а то негоже столько времени держать реквест в major-е. >>48818 Для тебя ничего не изменится — если ты, конечно, не залезешь в настройки и не поставишь галочку типа «разворачивать первое видео с ютуба в посте». >>48828 Чому бы не писать несколько постов, или не прикреплять пикчи ссылками? Если каждый будет лепить по десятку пикч к посту — то мы так очень быстро вылетим за наши 15 гигов. >>48832 >Какую такую видимую часть? Например, маленький экранчик, на нем видно, к примеру, три поста. Скроллишь пальцем вверх-вниз — подгружаются другие. >Можно просто потом добавить запрос на получение нужных постов параллельно к запросу на получение после определённого номера, хуже не станет. А я о чём говорю? Два варианта запросов, главное — есть и «быстрый», и «универсальный». >И, я уверен, это «потом» уже никогда не наступит или просто нигде не понадобится. Это невозможно гарантировать (как и обратное). >такая небольшая оплошность — и уже что-то перестаёт работать как надо. Само собой, для каждой борды нужны свои правки — и чем борда дальше от кусабы, тем больше. Но основа всё равно остаётся одна, и парсеры отличаются лишь немного, условно говоря, это не разные парсеры, а один и тот же с небольшой кастомизацией под конкретную борду. К примеру, никто не додумывался, например, посты лепить в, например, голый blockquote вместо td, или систему адресации постов типа '#reply12345' заменять на нечто своё, или стили перелопачивать до неузнаваемости. >Нужно доказательство всеобщности, а не существования, понимаешь? Теперь понимаю. Возможно, я слишком категорично сказал, но я говорил о тенденции, а не о непреложном правиле. >$.post. Передёшь в него JS объект — он сам из него формирует данные. Спасибо, буду знать. >Ради этого ты собираешься вводить свои велосипеды вопреки здравому смыслу. Да где же тут вопреки здравому смыслу-то? Вон, для обновления треда мне, к примеру, уже требуется передавать список постов (впрочем, я всё обновление делаю одним запросом). >Нет никакой необходимости формат входных и выходных данных делать идентичным, это абсолютно лишнее. Ну, необходимости — конечно же, нет. А когда входные и выходные данные представляют собой объекты — то почему бы их и туда, и сюда не передавать в одном формате? >Проблема в том, что ты плодишь сущности. Как раз-таки, без упрощенной схемы сущность (операция) одна: получить перечисленные посты. Понимаешь, не сервер должен думать, что с этим делать, это задача клиента. Серверу сказали «дай мне эти посты» — он дал. Упрощённая схема здесь исключительно для облегчения этой операции в наиболее часто используемом случае (получение новых постов). >Если сделать как раньше (404), то точно всё будет работать. Ок, сделаю тогда так. >Любой пост-запрос с содержимым надо во что-то кодировать. Погоди, а разве это делается не прозрачно для пользователя через FormData::append()? >Много. Не понимаю, к чему это. Я, если честно, ни разу не видел в выводе wireshark-а PUT или DELETE. Исключительно GET и POST. Это к тому, что не всё «в вебе» используется так, как задумано. >И ты ещё мой вариант костылём называешь? Ещё раз говорю: твой вариант предназначен для абсолютно конкретного случая (обновление треда) и более ни для какого. Естественно, именно в этом случае он работает лучше (а в других — не работает вообще). И я не говорю, что он не нужен, просто его наличие не отменяет наличия универсального интерфейса. >«Может быть понадобится» — не обоснование. Тем не менее, оно часто работает. >>48833 >Это же хардварь, и за каждую фичу нужно платить покупкой деталей. (Или ты оставляешь площадки?) Ну, если туда ставится редкая микросхема/соединитель — то да, помечаю их в схеме как незапаиваемые, а в спецификации и перечне элементов как «наличие определяется договором поставки, если не оговорено особо — отсутствует». Но в общем и целом над мыслью поставить лишний разъём-гребёнку со стоимостью в 10 рублей, резисторы со стоимостью меньше рубля штука или там микросхему стоимостью рублей в 20-50 (I2C EEPROM, например) даже задумываться не стоит — на фоне общей стоимости модуля в сотни тысяч рублей это копейки, а профит (хотя бы если его пересчитать в оплату человеко-часов) значительный. >Кстати, тут же вопрос: SPI может потянуть 10Мбит/сек на коротких дистанциях? Да, на 12 МГц мы его пускали. >Эта модель просто умерла в какое-то время. Вот и я о том же. Не всё «в вебе» сделано идеально, есть рудименты, есть просто неудобные или непродуманные вещи. >А потом по команде сервера должен удалять то, что пользователь желал бы прочесть. Я тебя понимаю, да (и сам раньше так думал). Но в целом, вот лично здесь — я старался привести ситуацию к тому, чтобы тред после обновления выглядел так же, как будто страницу целиком перезагрузили. Классическая ситуация: человек отправил пост, увидел в нем ошибку и переотправил его. Итог: если не удалять, то у читающего будут два поста: старый и новый. Некрасиво как-то, как по мне. В конце концов, если человек не хочет, чтобы у него удалялись (как и добавлялись) посты, он просто не будет обновлять тред, верно? >>48834 >Предположу, что имелась ввиду загрузка только малой части треда с последующей автоподгрузкой при надобности. Да. >Мы вообще-то новый движок пилим. Пока что только API. Хотя, если кто-то уже активно пилит движок, то я буду всячески благодарен такому герою =) >А я вообще сижу и не понимаю, почему бы серверу не вести историю. Это сложно (к примеру, я не представляю, как сервер будет отслеживать хотя бы тысячу одновременно подключенных клиентов) и очень чревато рассинхроном.
FormData::append()
>>48814 >Причём запрос списка постов неоправданно сложный, в отличии от моего варианта. Чем же сложен запрос списка по id? Простейший запрос, учитывая что id индексируется и уникально, то время выполнения линейно. >>48832 >Тебе как на клиенте, так и на сервере придётся выполнить больше разных вычислений. Сервер в этом случае ВООБЩЕ практически никаких вычислений не выполняет — он выполняет два запроса, в одном отдает id постов из треда, во-втором посты по id. А вот в твоем случае база вынуждена пробегать все посты после того, который ты отправишь как последний в треде, и смотреть, в каком треде эти посты находятся. >>48834 >почему бы серверу не вести историю. Для каждого клиента? А каждому клиенту история для каждого треда? Да ддосер с большим набором прокси все тут ушатает. >Обновления же каждые 20 сек. У меня автообновления отключены — уже не каждые 20 сек. >>48846 >Хотя, если кто-то уже активно пилит движок, Какой-то анон отписывался в прошлом треде, что пилит.
>>48846 >Это сложно и очень чревато рассинхроном. Разумеется, это нужно реализовывать отдельно. Но создать таблицу, и вписывать туда «тред 1234: в посте 2345 добавлен ответ в карту, время 101; тред 9999: добавлен пост 10000, время 102; тред 9999: добавлен пост 10001, время 103» Пользователь при надобности отсылает номер треда и время. Сервер уже отправляет (проверив на дубликаты, разве что. Ну или тупо отправив несколько раз одно и то же, всяко случай редкий). Можно ещё дополнять вида не помечать «карта ответов» или «пост», а сделать колонку «тип» и сразу дописывать в карту ответов только 1 добавление или 1 удаление. (хотя это уже похоже на мелочи. Хотя и сэкономим ещё чуть больше) Если сервер ответить не может (сообщение слишком давнее), то можно и обновить клиенту весь тред. Т.к. это уже не 20 секунд, и даже не час прошёл. >к примеру, я не представляю, как сервер будет отслеживать хотя бы тысячу одновременно подключенных клиентов. Эти же способом. Не серверу же следить за тем, на каком моменте какой клиент остановился, а клиенту.
>>48851 >Чем же сложен запрос списка по id? Простейший запрос, учитывая что id индексируется и уникально, то время выполнения линейно. Очень условно линейно, основная нагрузка тут О(1). Но вот только что делать, если изменение произошло? Кидать второй запрос, или загружать тред целиком? Более того, так уже происходило сравнение внутри клиента ещё во времена статики. Приводило это к тому, что удалёние постов не фиксировалось. Сразу подскажу, что нужно передавать последний id И количество постов. Учитывая, что добавить пост внутрь других нельзя, то этих данных уже будет достаточно. Но второй запрос при изменении делать нужно. Или весь тред пересылать. Что первое, что второе не так уж здорово.
>>48856 >Но вот только что делать, если изменение произошло? >Кидать второй запрос, или загружать тред целиком? Какой такой второй запрос? Запрос постов по id это и есть ВТОРОЙ запрос. Первый — это запрос всех постов в треде, причем благодаря этому фиксируются удаление. А потом клиент запрашивает только то, чего у него нет.
>>48857 >это запрос всех постов в треде запрос всех НОМЕРОВ постов Фикс.
>>48834> Предположу, что имелась ввиду загрузка только малой части треда с последующей автоподгрузкой при надобности.Последние посты только в голову приходят, а как это сделать — я уже говорил.> Какие велосипеды? Что ты несёшь?Я о JSON в теле запроса вместо привычных способов кодирования.> Кстати, твой вариант был предыдущим. Мы так хорошо полетели на удалённых постах.Если дополнительно запрашивать список постов, то не полетит. Этого нет в предыдущем варианте.> С историей последних изменений треда полегче будет ничего не упустить.Я, кажется, представляю, о чём ты говоришь. Идея прикольная, но я бы забил и просто весь тред грузил чтобы уж точно всё предусмотреть. Больно много возни будет.>>48846> Например, маленький экранчик, на нем видно, к примеру, три поста. Скроллишь пальцем вверх-вниз — подгружаются другие.Вообще не востребованно. Маленький экранчик будет просто грузить все посты. Если бы это было востребованно, давно бы это сделали, но ты первый это придумал.> Это невозможно гарантировать (как и обратное).Учитывая то, что никому кроме тебя такие запросы не нужны, вполне можно.> Ну, необходимости — конечно же, нет. А когда входные и выходные данные представляют собой объекты — то почему бы их и туда, и сюда не передавать в одном формате?Потому что это велосипед и так почти никто не делает. Если нет необходимости — лучше не усложнять, только проще будет.> Как раз-таки, без упрощенной схемы сущность (операция) одна: получить перечисленные посты. Понимаешь, не сервер должен думать, что с этим делать, это задача клиента.А почему не сервер? Ты так за это цепляешься, но у нас конкретная прикладная задача, сервер думает в рамках задачи. И если необходимости получать конкретные посты нет, а её нет, то не надо ничего усложнять.> Погоди, а разве это делается не прозрачно для пользователя через FormData::append()?Я не знаю, что это такое, но в любом случае ты это делаешь.> Это к тому, что не всё «в вебе» используется так, как задумано.Речь не о как задумано, а о как принято. Оказалось, что использовать только гет и пост — удобно.>>48851> Чем же сложен запрос списка по id? Простейший запрос, учитывая что id индексируется и уникально, то время выполнения линейно.Вот >>48832> > Тебе как на клиенте, так и на сервере придётся выполнить больше разных вычислений. Надо как сформировать массив номеров новых постов, так и SQL-запрос с этим самым where id in (...). В моём же случае вообще ничего делать не надо.> Сервер в этом случае ВООБЩЕ практически никаких вычислений не выполняет — он выполняет два запроса, в одном отдает id постов из треда, во-втором посты по id. А вот в твоем случае база вынуждена пробегать все посты после того, который ты отправишь как последний в треде, и смотреть, в каком треде эти посты находятся.Запрос при этом получается проще и, благодаря своей простоте, скорее всего быстрее. В твоём случае база должна побегать все посты и проверять их номер?
>>48863 >Надо как сформировать массив номеров новых постов, так и SQL-запрос с этим самым where id in (...) Массив формирует клиент, а в sql запрос просто передается этот полученный от клиента массив. >В твоём случае база должна побегать все посты и проверять их номер? С чего бы? У нас же индексация по id. >Запрос при этом получается проще Спорим нет? Возьмем крайний случай — предпоследний тред на последней странице и запустим там (виртуально) мой и твой вариант автообновления. Твой вариант — сначала запрос всех номеров постов в треде для проверку на удаленные, потом второй запрос с передачей id 10577 последнего поста — и база должна пробежать 48939-10577 постов чтобы убедится, что среди них нет нового поста в этом треде. Мой вариант — клиент запрашивает список всех постов, сверяет с имеющимся, убеждается, что там нет ничего нового и второй запрос не делает.
>>48940> Массив формирует клиент, а в sql запрос просто передается этот полученный от клиента массив.Из массива нужно сформировать сам селект. Массив сам себя не экранирует и в запрос не вставит.> С чего бы? У нас же индексация по id.Я не знаю, как устроены бд со всеми этими индексациями, но даже Хомура говорит, что скорость одинако мала. Тем более, можно, наверное, индексировать по нескольким столбцами?> Спорим нет? Возьмем крайний случайНастолько крайний, что выполнив такую проверку на клиенте даже в моём случае не придётся делать второй запрос.Но я больше стремлюсь к минимализации работы программисту, нежели компьютеру, тем более если нагрузка почти никакая. Как минимум в этом смысле — да, проще.
>>48854 >Но создать таблицу, и вписывать туда «тред 1234: в посте 2345 добавлен ответ в карту, время 101; тред 9999: добавлен пост 10000, время 102; тред 9999: добавлен пост 10001, время 103» Такое изобретение называется «система контроля версий». Для движка борды это, думаю, оверкилл, но теоретически такая схема возможна. Однако это уже совсем другой порядок размера базы и сложности извлечения из неё инфы. И уж тем более всего лишь ради сокращения сложности клиента, мне кажется, это не очень имеет смысл. Учитывая то, что вычислительная мощность сервера постоянна, а клиентов — растёт с их количеством. >>48856 >Но вот только что делать, если изменение произошло? Кстати, заметь: при автообновлении очень мал счётчик «попаданий» на событие «страница изменилась». >>48856 >>48857 Btw, уже сейчас давно как можно пользоваться json.update.php — в ответ на запрос из списка имеющихся у клиента постов прилетит и список удалённых постов, и html добавленных, и новая карта ответов треда. Это специально для тех, кто желает максимум вместить в один запрос. >>48863 >Я о JSON в теле запроса вместо привычных способов кодирования. Если $.post() имеет подобную функциональность, то я не против. Главное, чтобы при этом на сервере можно было бы легко разобрать то, что он сделал. >давно бы это сделали В мире, где под андроид две читалки для борд, а для IOS — вообще ноль. Угу. >Учитывая то, что никому кроме тебя такие запросы не нужны, вполне можно. Гинто ещё нужны. >но у нас конкретная прикладная задача, сервер думает в рамках задачи. Нет. Запрос к API — это не задача, это инструмент. Одним инструментом можно решать множество задач — важно уметь этим инструментом пользоваться. Например, вот у меня на кухне есть куча разных ножей — для хлеба, яблок, мяса, рыбы от прошлой хозяйки осталось, но когда я решаю, что взять с собой в поход — я беру один универсальный нож, потому что я знаю, что с его помощью я могу решить любую задачу, которую можно решить с помощью ножа. Правда, я до сих пор не могу понять, чем отличаются эти ножи, какой из них какой, и самое главное — какова разница в результате, лол. Так же и с запросом: если я даю возможность передавать параметры как через GET, так и через POST — то с помощью подобной абстракции можно решить даже те задачи, исходные данные для которых не вмещаются в 255 символов. >то не надо ничего усложнять. Писать $_REQUEST вместо $_GET — это усложнять? >Речь не о как задумано, а о как принято. И как же принято? В общем случае да, немодифицирующие запросы к серверу делаются с помощью GET. Но это не железное правило, а так «принято» просто потому, что во многих случаях так проще, когда не нужна функциональность POST. Но когда она нужна — она используется. Тот же контактик сыплет POST-ами при простом скролле ленты или сообщений — просто мама не горюй. >В моём же случае вообще ничего делать не надо. В какой раз уже говорю: если тебе достаточно «простой» функциональности — то и не делай. Я согласен, твоя задача распространена — поэтому я сделаю «упрощённый» вариант для неё. К чему же выпиливать более универсальную функциональность, нужную другим? >>48943 >Из массива нужно сформировать сам селект. Массив сам себя не экранирует и в запрос не вставит. Если не ошибаюсь, это делается автоматизированно (где-то в дебрях read.php надо глянуть). >Хомура говорит, что скорость одинако мала. Что время, затрачиваемое на выполнение запроса одинаково мало.
json.update.php
$.post()
>>48957> Гинто ещё нужны.Ну, на самом деле тоже окажется, что не нужны.> Одним инструментом можно решать множество задач — важно уметь этим инструментом пользоваться.Инструмент для задачи. А задачи таковы, что слишком универсальный инструмент не нужен.> но когда я решаю, что взять с собой в поход — я беру один универсальный нож, потому что я знаю, что с его помощью я могу решить любую задачу, которую можно решить с помощью ножа.У нас тут не поход, а одна лишь резка хлеба. И вот для неё ты решил взять универсальный нож.> Писать $_REQUEST вместо $_GET — это усложнять?Формировать сложный запрос вместо элегантного ии покрывающего все задачи сравнения.> И как же принято?> > application/x-www-form-urlencoded или multipart/form-data> Но когда она нужна — она используется.Вот когда нужна. Прямо очень нужна. Так нужна, что кушать не могу. Велосипедить весело только тому, кто пишет эти велосипеды, да и то во время обучения.> К чему же выпиливать более универсальную функциональность, нужную другим?Я пытаюсь объяснить, что универсальная функциональность тут в принципе не нужна. И даже не выпиливать: апи-то нет, нельзя выпилить то, чего ты ещё не сделал.Ты ни с того ни с сего взялся за абсолютно бесполезную сущность и даже не знаешь, зачем она нужна, мол, зато универсально. Сделай частный упрощённый запрос, а потом, когда время придёт, — общий, если понадобится. Видимо, это будет единственный способ для тебя убедиться, что упрощённый запрос покрывает все задачи.> Что время, затрачиваемое на выполнение запроса одинаково мало.Ага, оговорился, это и имел в виду.
>>48960 >Ну, на самом деле тоже окажется, что не нужны. Ну посмотрим. >А задачи таковы, что слишком универсальный инструмент не нужен. Лучше, когда он есть, чем когда его нет. >И вот для неё ты решил взять универсальный нож. Потому что резать хлеб настойчиво предлагаешь ты, а Гин хочет резать многое другое, вот как-то так. >Формировать сложный запрос Так запрос формирует клиент. Я же только предоставляю ему возможность этот запрос выполнить. >application/x-www-form-urlencoded или multipart/form-data Стоп, мы, вроде как раз про то, что всё получение надо делать GET-ом, или ты уже про что-то другое? Насчёт передачи в формах — это другой разговор, там надо изучать эту тему. Если объект легко передать через форму с помощью $.post и легко на сервере распарсить, то я против ничего не имею. >Прямо очень нужна. Так нужна, что кушать не могу. Контактику вот прямо очень нужен этот POST? >Ты ни с того ни с сего взялся за абсолютно бесполезную сущность и даже не знаешь, зачем она нужна, мол, зато универсально. Начнём с того, что эту сущность сначала попросила Гин, вообще-то. То есть, она уже нужна. Алсо, проще будет оба одновременно сделать, чем по отдельности.
$.post
Чет вы как-то все слишком усложняете. Будь на сервере вебсокеты нужно было бы просто рассылать посты субскрайберам, то же самое и с удалением, достаточно уведомить всех. Осталось только взять впс.
>>48943 >Массив сам себя не экранирует и в запрос не вставит. Хочешь сказать, что это долго? >>48957 >В мире, где под андроид две читалки для борд, а для IOS — вообще ноль. Здесь должен был быть ехидный коммент про пользователей iOS, но я промолчу. Потому что под мою OS тоже нет. >Правда, я до сих пор не могу понять, чем отличаются эти ножи Подозреваю, что ничем, просто здесь так заведено, и нож для мяса/рыбы не желательно лишний раз использовать для всякой мелочи вроде хлеба, чтобы не затуплять без необходимости. >>48960 >Формировать сложный запрос вместо элегантного ии покрывающего все задачи сравнения. Угу, элегантность сравнения только в том, что там букв в запросе меньше, лол. >Ты ни с того ни с сего взялся за абсолютно бесполезную сущность Не только он, а мы вдвоем. >>48975 Если бы еще производительности на них хватало...
>>48977 А тут не нужен уж какой-то сильный сервер, тем более соединений немного. В принципе даже реализация на пхп сгодится, а проблем решится куча.
>>48971> Стоп, мы, вроде как раз про то, что всё получение надо делать GET-ом, или ты уже про что-то другое?Мы о том, что ты хочешь в JSON данные предавать. А потом немного отошли и начали примеры из веба давать.> Контактику вот прямо очень нужен этот POST?Не знаю, я не смотрел код контактика и что он там отправляет.>>48977> Хочешь сказать, что это долго?Для программиста это дольше, больше кода.> Угу, элегантность сравнения только в том, что там букв в запросе меньше, лол.Ну да. Нет этого глупого массива из сколь угодно длинного набора номеров.> Не только он, а мы вдвоем.Да как-то выходит, что тебе она тоже не нужна, потому что частного запроса тебе тоже хватает, а единственная причина, по которой ты его хочешь использовать, — мнимая производительность сервера, которой на самом деле нет и которая клиента не должна беспокоить.
>>48981 >Для программиста это дольше, больше кода. Не знаю как в php, в питоне это все легло бы на sqlalchemy, а кода было бы практически одинаково. Впрочем, программист серверной части у нас Хомура — ей и решать. >Нет этого глупого массива из сколь угодно длинного набора номеров. Ты уперся лбом в то, что тебе, видите ли, не нравится этот массив, и пропагандируешь свой частный способ. >что тебе она тоже не нужна То есть ты будешь за меня решать, что мне нужно? >которая клиента не должна беспокоить. Да она и не будет — клиенту не будет никакой разницы, как его приложение там работает внутри, если оно новые посты подгружает.
>>48984> Ты уперся лбом в то, что тебе, видите ли, не нравится этот массив, и пропагандируешь свой частный способ.Я ценю красоту и простоту кода.> То есть ты будешь за меня решать, что мне нужно?Расскажи тогда, где тебе это нужно, когда тебе частного запроса не хватает? Я так решил потому что ты рассказала, что тебе нужно, и всё это решается частным запросом. Быть может, нужно что-то ещё, но я об этом уже не знаю, просто придумать ещё что-то не получается.> Да она и не будет — клиенту не будет никакой разницы, как его приложение там работает внутри, если оно новые посты подгружает.Клиент это само приложение. Я имел в виду что тебе, как разработчику, должно быть всё равно, используется ли на сервере индексирование при каком-то запросе или нет.
>>48975 Мы же вроде уже решили, что вебсокеты для нас — это слишком, ибо всё решается простыми средствами, а выслушивать «у меня Курисачик перестал открываться, потому что админы режут всё, кроме 80 (и 443) порта» я не хочу. >>48977 >просто здесь так заведено Вот да. Я называю такие причины терминальными — потому что на них и возражать как-то невозможно, и соответствующую тему обсуждения можно считать исчерпанной, лол. >и нож для мяса/рыбы не желательно лишний раз использовать для всякой мелочи вроде хлеба Ну, это нормальное обоснование. Впрочем, в нашем случае мы считаем, что ножи (запросы) можно использовать бесконечно, да, так что тут пример не очень точный. >>48981 >Мы о том, что ты хочешь в JSON данные предавать. Я не против любого другого настолько же универсального формата. Передавать в виде формы — не вопрос, если это легко парсится на стороне сервера (да) и легко упаковывается на стороне клиента (javascript с jquery — видимо, да; то, на чём пишет Гин — не знаю, надо смотреть). >Для программиста это дольше, больше кода. Кода там ненамного больше по сравнению с предоставляемыми им возможностями. >>48987 >и всё это решается частным запросом. Ещё раз: твоим запросом не решается, например, скрытие удалённых постов. Короче, я уже вижу, что к какому-то консенсусу мы не придём. Есть два подхода со своими плюсами и минусами: «сервер — инструмент» (когда бизнес-логика в клиенте, а сервер просто предоставляет всю возможную функциональность) и «сервер — решальшик задач» (когда есть строго определённый круг задач и под каждую задачу свой, сугубо специфический запрос к серверу, который выдаёт всё в наиболее типичном для задачи формате). Пример первого — Linux, пример второго — iOS. И вот это «объяснить пользователю, что ему нужно совсем не то, что он хочет, а то, что может предоставить интерфейс», которое характерно для второго варианта, меня иногда раздражает. Лично я считаю, что нужно давать всю возможную функциональность (первый вариант), быть может, с возможностью коротких вызовов для реализации «особо популярных» задач (второй вариант). Думаю, в таком виде это удовлетворит всех, кроме хейтеров первого варианта, да.
>>49027 Мы уже обсудили что вебсокеты только для автообновления.
>>48863 >Я, кажется, представляю, о чём ты говоришь. Идея прикольная, но я бы забил и просто весь тред грузил чтобы уж точно всё предусмотреть. Больно много возни будет. Как бы тебе сказать. Примерно в таком режиме Курисач уже год как работал. Мы тут не для кодопозитива собрались, нужно развиваться. >Учитывая то, что никому кроме тебя такие запросы не нужны, вполне можно. А я бы не был так категоричен. Более того, Хомура уже говорил, что это предусмотреть дополнительно несложно. И в первую очередь он и принимает решение, как технически будет работать Курисач. >Потому что это велосипед Мы вообще новый движок сейчас изобретаем. Мне даже и сказать про велосипеды нечего, правда. >и так почти никто не делает Взывать к популярности. Хорошо, что для Хомуры это посредственный аргумент. Можешь ещё раз объективно объяснить, чем это плохо? >Если нет необходимости — лучше не усложнять, только проще будет. Необходимость — понятие очень растяжимое. Объективно говоря, для наших задач каждый раз пересылать разметку — лютый overkill, каждый раз устанавливать http-запросы — лютый overkill. В шифровании SSL необходимости тоже нет. Более того, в автообновлении как таковом необходимости нет. Работали и без неё. В оповещениях необходимости особой тоже нет. Это всё для удобства. Вот и JSON был бы неплох для удобства разработки. Если он будет лишним, и вызовет больше неудобств — тогда, конечно, он будет лишним. >И если необходимости получать конкретные посты нет, а её нет, то не надо ничего усложнять. Ты предлагаешь при обновлении стягивать сразу все посты? Вот тут явно протестую: скорость загрузки как по траффику, как по процессору возросла во много раз после перехода на динамику. >но я бы забил и просто весь тред грузил чтобы уж точно всё предусмотреть. Больно много возни будет. Знаешь, я тут кое-что заметил в этих словах. Да, тебе удалось меня довести всего за один пост ^_^ Это не «я бы забил», это ты каждому курисачеру предлагаешь вот так просто грузить каждый раз весь тред с нуля и перестраивать разметку. Хомура уже нас избавил от такой модели обновлений. Потому, что это важно.>>48957 >Такое изобретение называется «система контроля версий». Да, так и называется. >И уж тем более всего лишь ради сокращения сложности клиента, мне кажется, это не очень имеет смысл. >Учитывая то, что вычислительная мощность сервера постоянна, а клиентов — растёт с их количеством. Погоди-ка, это снизит нагрузку и на сервер. Я бы не предлагал, если бы это было тяжелее. Взгляни сам: в большинстве случаев там 0 обновлений, и сервер сразу говорит, что всё на месте. В данный же момент ему нужно сверять для этого имеющиеся номера постов. Когда там 1-2 обновления, это всё ещё будет проще, чем сверять все посты, и вычленять из них недостающие. Отличие от способа «по последнему id и количеству» я уже говорил: такой способ более универсальный, он поддерживает редактирование постов без изменения id и добавление/удаление кросс-тредовых ответов. Если же последние две фичи не нужны, то считаю способ «last id + last post number» наиболее оптимальным. Разве что для удаления/переотправки он требует загрузки всего треда заново. >Кстати, заметь: при автообновлении очень мал счётчик «попаданий» на событие «страница изменилась». Да, поэтому я и говорю, что нужно наиболее оптимизировать на случай, когда ничего не происходит. У постояльцев (которые основную нагрузку и дают) ещё и открыто несколько тредов сразу. Но и обновление всего треда — явление нежелательное. >В мире, где под андроид две читалки для борд, а для IOS — вообще ноль. Тогда нам ещё нужна мобильная веб версия. >Btw, уже сейчас давно как можно пользоваться json.update.php — в ответ на запрос из списка имеющихся у клиента постов прилетит и список удалённых постов, и html добавленных, и новая карта ответов треда. Это специально для тех, кто желает максимум вместить в один запрос. О, спасибо. >Если не ошибаюсь, это делается автоматизированно (где-то в дебрях read.php надо глянуть). Не представляю, о каком «автоматизированно» ты говоришь. >Что время, затрачиваемое на выполнение запроса одинаково мало. Опять ты их насилуешь, хехе?>>48975 >Будь на сервере вебсокеты нужно было бы просто рассылать посты субскрайберам, то же самое и с удалением, достаточно уведомить всех. О, адепт вебсокетов тоже тут. Привет.>>48977 >Если бы еще производительности на них хватало... Как раз вебсокеты — самая лучшая модель по загрузке процессора. Только вот с оперативной памятью беда: на каждое соединение постоянно висит отдельный серверный процесс. Да и не все платформы/браузеры/конфигурации поддерживают вебсокеты. Тот же Kaspersky, да и многие другие антивирусы, например, блокируют вебсокеты просто «на всякий случай».>>48981 >Для программиста это дольше, больше кода. Ты уже что-то пишешь?>>49027 >Есть два подхода со своими плюсами и минусами Всё равно нам нужен будет fallback, и простой интерфейс обновления всего треда целиком (либо постранично, если всё пойдёт дальше) Так что лучше сразу предоставить пользователю на выбор два стула интерфейса, а он пускай решает, что делать. Для внешнего парсинга может быть простой интерфейс с полным обновлением предпочтительнее. А для более продвинутого (в т.ч. браузерного) интерфейса желателен вариант с наименьшими нагрузками.
>>49173 >О, адепт вебсокетов тоже тут. Я периодически захожу почитать. Глядя какие костыли предлагают, я невольно задумываюсь над тем зачем, зачем они это делают? Я кстати закончил модуль работающий с файлами. Завтра приступлю непосредственно к реализации самой доски.
>>49052 Хорошо, тогда выслушивать «у меня тред перестал обновляться, почините» тоже не очень. >>49173 >В данный же момент ему нужно сверять для этого имеющиеся номера постов. Ну сравнение массивов не более 500 uint32_t — очень быстрая операция, как правило, это даже вмещается в одну кэш-строку процессора, так что в идеале выполняется за те же 500 тактов (другое дело, что перед собственно сравнением его его потаскают по памяти и т.п.) Даже SELECT выполняется несоизмеримо дольше (а сервер ведь должен узнать, чё там у базы). >Когда там 1-2 обновления, это всё ещё будет проще, чем сверять все посты, и вычленять из них недостающие. Но эти все обновления нужно будет хранить неограниченное время — а ведь это дублирование данных в базе и её сильное разрастание. >Если же последние две фичи не нужны, то считаю способ «last id + last post number» наиболее оптимальным. Разве что для удаления/переотправки он требует загрузки всего треда заново. Но у нас ведь есть и карта ответов, и удаление постов бывает — поэтому проще обмениваться списком постов и картой ответов (это пара килобайт туда и пара десятков килобайт оттуда). >Да, поэтому я и говорю, что нужно наиболее оптимизировать на случай, когда ничего не происходит. Да, сейчас как раз так и есть: если сервер вернул карту ответов и список постов, идентичные тем, что были до обновления, тогда на странице вообще ничего не модифицируется. >Тогда нам ещё нужна мобильная веб версия. Кстати да, наверное, нужно допилить мобильную версию до вменяемого уровня. >Не представляю, о каком «автоматизированно» ты говоришь. Да, кстати, сейчас тоже посмотрел и понял, что там что-то какая-то ересь, всё вручную делается. И что это всё надо переписывать, лол. >Так что лучше сразу предоставить пользователю на выбор два интерфейса, а он пускай решает, что делать. Вот и я о том же. Кстати, Курисач, я сейчас думаю над реализацией картинки + видео. Думаю сделать так: 1) при постинге с видео — вместо создания видеобокса в посте я в начало поста дописываю ссылку; 2) отключаю всю функциональность видобокса и эмбеддинга видео на сервере; 3) переношу превращение ссылки в видеобокс в kusaba.new.js; 4) делаю галочку в настройках «превращать ссылки на youtube, coub, vimeo в видеобокс» 5) если галочка выключена, то в каждом посте в видео превращается только первая ссылка, если до неё нет никакого текста и к посту не приаттачена картинка; 6) если галочка включена, то превращаются все распознанные ссылки в тексте вне зависимости от того, есть ли в посте картинка или нет. Как вам идея? Какие подводные камни?
>>49027> Ещё раз: твоим запросом не решается, например, скрытие удалённых постов.А как это решается твоим? В 2 запроса? Не смеши меня.>>49173> Мы вообще новый движок сейчас изобретаем. Мне даже и сказать про велосипеды нечего, правда.Одно дело изобретать движок, другое — новые способы передачи данных.> Взывать к популярности.Потому что популярно значит допустимо. Непопулярно значит нужно в конкретных случаях, когда не хватает популярного варианта. Это не наш случай.> Можешь ещё раз объективно объяснить, чем это плохо?И первого раза не было. Я не веб разработчик и вообще не изучал историю и принципы работы веба настолько хорошо, чтобы точно знать, чем JSON плох. Единственное, что я могу предложить, — формы умеют прозрачно кодировать и декодировать все клиенты и сервера. А вот в случае с JSON это всегда будет лишняя работа программисту как на сервере, так и на клиенте.Надо думать, прежде чем делать что-то необычное, а не делать необычное ради необычного.> Необходимость — понятие очень растяжимое.Ты привёл реально необходимые вещи.Нет необходимости передавать разметку? Передавайте JSON. Что-то так или иначе придётся передавать. И вообще сделать бы надо...Про запросы не понял, но у нас веб-браузеры, они только по HTTP умеют общаться с серверами.В шифровании есть необходимость, это обеспечение безопасности.Всё, что ты пишешь дальше, имеет необходимость: стало удобнее.От использования JSON как формата для передачи данных удобнее никому не станет, как я уже сказал, как минимум добавиться явный шаг для его кодирования и декодирования, потому что его поддерживает меньшее число серверов/клиентов. А единственный аргумент за него — «можно передавать массивы массивов», ороро.> Ты предлагаешь при обновлении стягивать сразу все посты?Все посты после последнего.> Это не «я бы забил», это ты каждому курисачеру предлагаешь вот так просто грузить каждый раз весь тред с нуля и перестраивать разметку.Потому что слишком много всего тут сейчас надо предусмотреть, и всё из-за карты ответов. Например, если на пост Х ответили из другого треда, сейчас без полной загрузки треда этого не узнать. Придётся много возиться.>>49332> Кстати, Курисач, я сейчас думаю над реализацией картинки + видео.Не надо усложнять с этой первой ссылкой. Просто убери возможность прикреплять видео, а все ссылки преобразуй в видео боксы. Если в настройках выключена галочка, то вообще ничего не преобразуй.
Я заюзала свой недописанный движок для того, чтобы на нем тестировать клиент. Таки пригодилось. >>49027 >в нашем случае мы считаем, что ножи (запросы) можно использовать бесконечно Использовать какой-то сложный (по нагрузке) запрос для чего-то простого лучше не стоит, как использовать для хлеба нож для мяса. >>49173 >Только вот с оперативной памятью беда Это, в общем-то, тоже проблема с производительностью, причем VDS с большим количеством оперативы нынче дороги. >>49382 >не изучал историю и принципы работы веба настолько хорошо, чтобы точно знать, чем JSON плох. Не знаем, но уже не любим. Шикарно. >формы умеют прозрачно кодировать и декодировать все клиенты и сервера И JSON тоже — фактически везде есть под это утилиты. >его поддерживает меньшее число серверов/клиентов Что не поддерживает JSON? Brainfuck?
>>49396> Не знаем, но уже не любим. Шикарно.Кто не любит? Нужны серьёзные причины для чего-то нестандартного, только и всего. Меня попросили объективные причины чтобы не использовать — я таких не знаю, хотя одну и вспомнил, но дело не в этом.> И JSON тоже — фактически везде есть под это утилиты.Речь не об утилитах, а о фактической поддержке клиентами и серверами, без необходимости дополнительной конвертации, и не важно, ручками ты это делаешь или библиотекой. Потому что формат форм — это стандарт, JSON — нет.> Что не поддерживает JSON? Brainfuck?> > добавиться явный шаг для его кодирования и декодирования
Пока криво и недоделано, но уже что-то. Я в восторге от QML, который сам на себя берет отображение большей части HTML-форматирования (например, эту ссылку) и освобождает меня от парсинга. >>49519 >для чего-то нестандартного >Потому что формат форм — это стандарт, JSON — нет. JSON уже c 2014 международный общепризнанный стандарт. > > > добавиться явный шаг для его кодирования и декодирования Строчка в начале и строчка в конце. Тоже мне сложности.
>>49382 >А как это решается твоим? В 2 запроса? Не смеши меня. Можно в два, можно сделать и в один (сейчас автообновление так работает — в один запрос делает всё). >Непопулярно значит нужно в конкретных случаях, когда не хватает популярного варианта. Это не наш случай. Имхо, как раз наш, если мы, конечно, о передаче массива, а не о дилемме JSON/формы. >Единственное, что я могу предложить, — формы умеют прозрачно кодировать и декодировать все клиенты и сервера. А вот в случае с JSON это всегда будет лишняя работа программисту как на сервере, так и на клиенте. Давай разберём по частям всё тобой написанное. 1. Формы. 1.1. Клиент: $.post(url, ...); — jQuery. Не «прозрачно», но просто. foo = new FormData; foo.append(...); bar = new XMLHTTPRequest; bar.send(foo); — чистый javascript. Нифига не прозрачно. Остальные языки — не знаю, как. В каких-то, быть может, просто/прозрачно, в каких-то нет. Для примера, в PHP я прозрачного метода для POST-запросов не видел. Только такой: $options = array( 'http' => array( 'header' => "Content-type: application/x-www-form-urlencoded\r\n", 'method' => 'POST', 'content' => http_build_query($data) // $data = array('key1' => 'value1', 'key2' => 'value2', ...); ) ); $context = stream_context_create($options); $result = file_get_contents($url, false, $context); 1.2. Сервер: $data = $_REQUEST; — да, согласен, прозрачно. 2. JSON. 2.1. Клиент: $.post(url, ...); — jQuery. Так же. foo = new FormData; foo.append('data',JSON.stringify(data)); bar = new XMLHTTPRequest; bar.send(foo); — чистый javascript. То же самое, за исключением того, что FormData::append() вызывается только один раз для всех передаваемых данных — а значит, код одинаков для любого формата входных данных. В предыдущем случае придётся перебирать все данные, которые мы хотим отправить. 2.2. Сервер: $data = json_decode($_REQUEST['data']); — не совсем прозрачно, но элементарно понятно. И вот ради того, чтобы избежать вот этого вот усложнения в 21 символ, стоит мутить крокодилы с формами на клиенте? > потому что его поддерживает меньшее число серверов/клиентов. WAT >Например, если на пост Х ответили из другого треда, сейчас без полной загрузки треда этого не узнать. WAT Сейчас для этого перезагрузки треда не требуется, только перезагрузка карты ответов (в JSON, кстати), что несоизмеримо быстрее и проще. >Если в настройках выключена галочка, то вообще ничего не преобразуй. Но это нарушило бы привычную функциональность. А мой подход таков: при запиливании новой фичи для тех, кому эта фича не нужна, не должно ничего измениться. >>49396 >Таки пригодилось. Кухихи, вот, оказывается, какая ему судьба была предназначена. Алсо, запилил-таки видео + картинку. Немного, правда, по-другому: 1) при постинге с видео — вместо создания видеобокса в посте я в начало поста дописываю ссылку — да, переписана функция embeddedVideoBox(); 2) отключаю всю функциональность видобокса и эмбеддинга видео на сервере — поскольку ссылка дописывается сервером (чтобы не ломать уже отправленные посты), не стоит этого делать; 3) переношу превращение ссылки в видеобокс в kusaba.new.js — да, сделан «класс» embed_class { init(); process_links(); } ; 3.5) т.к. эта замена длится долго, теперь медленнее грузятся посты с кучей видео, особенно с vimeo и coub, у которых нет простого пути получить тамбнейл (если кто подскажет, буду очень благодарен), и приходится сразу на страницу пихать iframe с плеером — я делаю эту замену только в тех постах, что пришли от сервера, а не во всех видимых (в частности, при развороте поста, всплывании поста, предпросмотре и т.п. грузится только один пост, поэтому заменять нужно только в нём); 4) делаю галочку в настройках «превращать ссылки на youtube, coub, vimeo в видеобокс» — да; 5) если галочка выключена, то в каждом посте в видео превращается только первая ссылка, если до неё нет никакого текста и к посту не приаттачена картинка — сделано хитрее: embeddedVideoBox() ставит ссылкам класс alwaysvisible — они видны всегда; остальные — только при включённой галочке; 6) если галочка включена, то превращаются все распознанные ссылки в тексте вне зависимости от того, есть ли в посте картинка или нет — да. Инфа о том, как юзать — см. >>49597.
$.post(url, ...);
foo = new FormData; foo.append(...); bar = new XMLHTTPRequest; bar.send(foo);
$options = array( 'http' => array( 'header' => "Content-type: application/x-www-form-urlencoded\r\n", 'method' => 'POST', 'content' => http_build_query($data) // $data = array('key1' => 'value1', 'key2' => 'value2', ...); ) ); $context = stream_context_create($options); $result = file_get_contents($url, false, $context);
$data = $_REQUEST;
foo = new FormData; foo.append('data',JSON.stringify(data)); bar = new XMLHTTPRequest; bar.send(foo);
$data = json_decode($_REQUEST['data']);
>>49275 >Я кстати закончил модуль работающий с файлами. Завтра приступлю непосредственно к реализации самой доски. О, молодец. >Ну сравнение массивов не более 500 uint32_t — очень быстрая операция, как правило, это даже вмещается в одну кэш-строку процессора, так что в идеале выполняется за те же 500 тактов (другое дело, что перед собственно сравнением его его потаскают по памяти и т.п.) Даже SELECT выполняется несоизмеримо дольше (а сервер ведь должен узнать, чё там у базы). Ну погоди, мы же говорим про базу данных. Сравнение интов — дело нехитрое. Больше вопрос в том, сколько должен выполнить сервер БД, чтобы из 500 строк повытягивать по 1 инту. Ему нужно довольно много побегать по связям для этого. А результат примерно тот же: после выполнения запроса веб сервер сразу знает, что именно у сервера БД запрашивать. >Но эти все обновления нужно будет хранить неограниченное время — а ведь это дублирование данных в базе и её сильное разрастание. Но не нужно же хранить ВСЕ изменения? Только последние 4-20 минут, всё старее можно удалять. Такой запрос даже за O(n) будет лёгким, будь за последние 20 минут хоть 1000 постов. Не дай бог такой темп на Курисаче >Но у нас ведь есть и карта ответов, и удаление постов бывает — поэтому проще обмениваться списком постов и картой ответов (это пара килобайт туда и пара десятков килобайт оттуда). Ну да. Удаление поста приведёт к перезакачиванию всего треда. >если сервер вернул карту ответов и список постов, идентичные тем, что были до обновления Погоди, карта ответов, как результат, так вся каждое обновление и пересылается? Да и запрос на составление 500 даже номеров — не самая простая задача. Хоть и да, это один запрос к базе, а не два. (Хотя постой, что-то мне подсказывает, что в SQL можно сразу написать сложный запрос вида: на каждую строку, принадлежащую моему треду и позднее «часа Х» достать пост по номеру из её же колонки «пост») Ладно, я и так понял: Подход весьма хорош. Но реализации требует тщательной и аккуратной. Как результат, что с него толку, если я его не пишу. >Кстати, Курисач, я сейчас думаю над реализацией картинки + видео. >Думаю сделать так >Как вам идея? Хмм, а костыль действительно неплох. >Какие подводные камни? Webm не продуман вообще. Всё же, там нужна и полноценная картинка, и полноценное видео. Других, вроде бы, не вижу.>>49382 >новые способы передачи данных. Телепатию через Нибиру рептилоидами >Потому что популярно значит допустимо. А непопулярно, значит, недопустимо уже? Это не смешно. >А вот в случае с JSON это всегда будет лишняя работа программисту как на сервере, так и на клиенте. В этом-то и дело, что тут ты и неправ. Есть удобные методы для работы с JSON. Как на сервере, так и на клиенте. Это Хомура и подметил: почему бы их не применить. А методы настолько удобные, что данными можно манипулировать сразу как массивами по имени (ассоциативными). >потому что его поддерживает меньшее число серверов/клиентов Стандарт Javascript определяет, что должны все. И уже 100 лет как. PHP сервер уже 100 лет как умеет. А новые так изначально с этой функциональностью на борту построены. Снова мимо. >Все посты после последнего. Уже говорили же: а что будем делать при удалении? Я уж не говорю тут, что от редактирования с сохранением номера мы отказались.>>49396 >причем VDS с большим количеством оперативы нынче дороги. Оперативная память осталась дорогой.>>49609 >Алсо, запилил-таки видео + картинку. Да, любопытно. Буду обкатывать.
Ну что, обкатываем: https://www.youtube.com/watch?v=TfH2Zw_YKKk Однострока: Тест 2: https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk Чуточку кода:https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk Inline-кода: https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk Экран-тесты https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk Тест555https://www.youtube.com/watch?v=TfH2Zw_YKKk И как нас тут видно, на днище, капитан?
Однострока:
https://www.youtube.com/watch?v=TfH2Zw_YKKk https://www.youtube.com/watch?v=TfH2Zw_YKKk
>>49585> JSON уже c 2014 международный общепризнанный стандарт.Который ни один браузер не поддерживает в формах, например.> Строчка в начале и строчка в конце. Тоже мне сложности.А можно просто не использовать JSON и не надо вообще ничего добавлять.>>49609> Можно в два, можно сделать и в один (сейчас автообновление так работает — в один запрос делает всё).Одним — это как?> Имхо, как раз наш, если мы, конечно, о передаче массива, а не о дилемме JSON/формы.Для массива и формы хватит. Массива в массиве у вас нет.> Остальные языки — не знаю, как. В каких-то, быть может, просто/прозрачно, в каких-то нет. Для примера, в PHP я прозрачного метода для POST-запросов не видел. Только такой:Очевидно, потому что пхп — серверный язык и не особо подходит чтобы самому запросы делать.> И вот ради того, чтобы избежать вот этого вот усложнения в 21 символ, стоит мутить крокодилы с формами на клиенте?Так где крокодилы на клиенте? На пхп что ли?> WATЯ о прозрачном кодировании/декодировании.> Но это нарушило бы привычную функциональность.Которая, в общем-то, никому не нужна. Сделай предупреждение, что всё, как раньше работать не будет, 2010 год давно закончился и пора сделать по-людски. Никто против и не будет даже.>>49648> А непопулярно, значит, недопустимо уже?А непопулярно значит читай хоть немного дальше того предложения, на которое собираешься отвечать.> А методы настолько удобные, что данными можно манипулировать сразу как массивами по имени (ассоциативными).Сомневаюсь, что такие методы понадобятся. С $_request ведь тоже как с ассоциативным массивом работаешь.> Стандарт Javascript определяет, что должны все. И уже 100 лет как.А при чём тут JS? У меня в курле его нет, например. Да и речь о прозрачном кодировании. Даже браузеры этого не умеют. А через формы не умеют даже непрозрачно.> Уже говорили же: а что будем делать при удалении?2 запроса. В общем-то, запрос по номерам в любом случае требует предварительный запрос номеров. Отсюда и узнаем удалённые.Заодно придумал новый аргумент, чем плох JSON: банально сложнее тестировать и вникать в принципы работы. С формами всё легко: можно легко клиентом кодировать, можно курл использовать, можно хоть в браузере через адресную строку смотреть результат. Апи обычно не для себя любимых делают.
Попробуйте открыть последние 50 постов любого треда.
>>49669 Удваиваю реквест починки. Очень неудобно весь тред скроллить с телефонов, грузится долго.
>>49670 Присоединюсь с просьбой туда же (в 404 хендлер) починить этот чёртов контроль кеширования. Уже не раз замечал, что при загрузке страницы браузер берёт версию, что у него была ещё вчера, вместо обновления.
>>49651 О святая Мадо-ками сама! Нашествие бобров! К такому меня жизнь не готовила, ведьмы как-то проще =) (btw, видно нормально, в коде, само собой, ссылки не раскрываются, заэкранированные тоже). >>49669 >>49670 >>49678 Почистил кэш клауды. Если почистить и кэш браузера тоже, то должно быть норм. Проверяйте, плз. Вообще не понимаю, почему клауда пытается кэшировать вот с таким убойным комплектом директив .htaccess: <Files *.html> RequestHeader add Cookie "prevent-caching" early Header add Expires "Mon, 26 Jul 1997 05:00:00 GMT" Header add Pragma "no-cache" Header add Cache-Control "must-revalidate, no-cache, no-store" Header unset Last-Modified Header unset ETag Header unset Vary </Files> Или ей наплевать, что запрос идет к .html, если он заканчивается 404? Тем более, что как ни странно, в заголовках ответа этих параметров нету... Короче, надо будет разбираться. На >>49648 и >>49666 отвечу вечерком. Хомура мимозабежавшая на Курисач
<Files *.html> RequestHeader add Cookie "prevent-caching" early Header add Expires "Mon, 26 Jul 1997 05:00:00 GMT" Header add Pragma "no-cache" Header add Cache-Control "must-revalidate, no-cache, no-store" Header unset Last-Modified Header unset ETag Header unset Vary </Files>
К-кстати у кого баги с обновление постов в Последние 50 постов зайдите в опции и поставьте галочку «Использовать старый метод обновления треда ». Это временное решение должно помочь, пока не починят.
С сегодняшнего дня у меня в опере мини снова вместо капчи значок загрузки. Единственный способ увидеть капчу, чтобы запостить в тред — зайти напрямую на kurisa.ch/captcha.php Можно ли вернуть, как было?
>>49648 >сколько должен выполнить сервер БД, чтобы из 500 строк повытягивать по 1 инту На самом деле, совсем немного — запрос элементарный: WHERE 'parentid' = $threadid, и всё (ну, ещё boardid, но он тут не важен). Другое дело — когда нужно получить последние посты: тут или WHERE 'parentid' = $threadid AND 'id' > $lastid, или WHERE 'parentid' = $threadid AND 'timestamp' > $last_update. Вытягивать инты ему всё равно придётся, просто в последнем случае он их не будет класть в выходной массив. А мой опыт кусабошатания говорит о том, что быстрее получается вытащить из базы сразу больше, но более простым запросом, а потом отсеять (если надо) уже в скрипте. >Только последние 4-20 минут, всё старее можно удалять. Но это означает, что все, кто обновляет треды реже, чем в 20 минут (а это вполне нормально, если автообновление отключено) — пролетают с «красивым» механизмом автообновления, так? >спойлер Было как-то за ночь, когда вайпали, лол. Если интересно, могу выгрузить csv из админки с темпом постинга или даже сделать xls за последние 400 дней (воу, так у нас же юбилей!) с красивыми графиками. >Погоди, карта ответов, как результат, так вся каждое обновление и пересылается? Да, ибо в ней не так уж много ссылок (в одном из рандомов, близком к бамплимиту намерил 1200 элементов). Сравнивать проще на клиенте, иначе бы пришлось гонять карту туда-обратно, а так — только обратно. >в SQL можно сразу написать сложный запрос вида: на каждую строку, принадлежащую моему треду и позднее «часа Х» достать пост по номеру из её же колонки «пост» Хм. Вроде вполне себе простой запрос, нет? SELECT 'message' FROM ... WHERE 'parentid' = ... AND 'timestamp' > ... >Всё же, там нужна и полноценная картинка, и полноценное видео. Для этого, увы, нужен ffmpeg. Ту самую javascript-реализацию ffmpeg на стороне клиента я рассматриваю исключительно как анекдот, да. =) Соответственно, этот реквест у меня поставлен в статус DELAYED. Но вообще, webm будет работать как обычный файл (и да, одновременно прикреплять webm и картинку будет нельзя — это же всё равно, что прикрепление нескольких картинок). >А методы настолько удобные, что данными можно манипулировать сразу как массивами по имени (ассоциативными). Да, именно это я и пытаюсь сказать. >от редактирования с сохранением номера мы отказались. Ну от него мы отказались презде всего по реквестам здешних жителей. >>49666 >Который ни один браузер не поддерживает в формах Не очень понял. В форму можно запилить поле со значением, в котором будет JSON-строка и сервер спокойно может это поле распарсить. Или ты про то, что JSON в «голом» виде не передаётся? Ну так HTTP тоже, иснкапсулируется в TCP-соединения, те — в IP-пакеты, а те — в Ethernet-фреймы, например. Дополнительный уровень абстракции здесь имеет не такой уж и большой оверхед по сравнению с удобством. >А можно просто не использовать JSON и не надо вообще ничего добавлять. Как видно из моего поста (>>49609) — надо (к примеру, зависящая от типов данных сборка формы на javascript, если не использовать jQuery). >Одним — это как? Туда — список отображённых постов в треде, оттуда — новый список постов, обновлённая карта ответов и html-кусок для дописывания в конец треда. Кстати, да, узкоспециальизированный инструмент строго для одного применения. Такова цена одного запроса вместо двух. >Массива в массиве у вас нет. Ну, как минимум, от сервера прилетает карта ответов в таком виде. От клиента тоже может понадобиться что-либо передавать. Вообще, я смотрю, разговор из предметной области ушёл в рассуждения о высших материях. Мне со стороны сервера совершенно не сложно одинаковым образом разбирать как классический $_REQUEST, так и $_REQUEST['json_data']. Вплоть до того, что можно будет написать if (isset($_REQUEST['json_data'])) $_REQUEST = json_decode($_REQUEST['json_data']) и дальше вообще не задумываться, каким образом прилетели исходные данные. А те, кто пишут клиенты, как хотят, пусть так и пишут. >пхп — серверный язык и не особо подходит чтобы самому запросы делать. Само собой, это был исключительно пример. >Так где крокодилы на клиенте? В многократных FormData::append(). >Я о прозрачном кодировании/декодировании. Я больше чем уверен, что всё, что может отправлять формы, кроме специальных утилит, что только это и умеют, умеет работать и с JSON. >Которая, в общем-то, никому не нужна. Сделай предупреждение, что всё, как раньше работать не будет Если можно сделать так, чтобы этого избежать, и это не труднее — то я считаю, что функциональность надо сохранять. И меня бесит, когда остальные думают противоположным образом и в новых версиях прог выпиливают привычную функциональность. >Никто против и не будет даже. Я буду, например. Мне удобнее ссылку пастить в поле, а не крутить текстбокс куда-то там вверх, когда в нём 30 кб текста. >С $_request ведь тоже как с ассоциативным массивом работаешь. Одноуровневым. JSON более гибок в плане многоуровневых массивов. >У меня в курле его нет, например. О святая Мадо-ками-сама! Да успокойся уже, будет тебе интерфейс с формами, если ты хочешь curl-ом читать Курисач. Да, если человек хочет извращений — я не вправе ему этого запретить. =) А для тех, кому удобнее запихнуть всё в json и не копаясь с формами, отправить одним полем — будет json. Кстати, curl — это как раз такая утилитка про котоую я говорил выше (которая больше ничего не умеет — и не должна уметь, в общем-то). >банально сложнее тестировать и вникать в принципы работы. WAT Ты «сырой» JSON нигде не читаешь, на клиенте данные в него пакуются уже после того, как скомпонованы, а на сервере ты их видишь уже после распаковки. >>49669 Да, это я хотел починить обновление «последних 50 постов» и «первых 100 постов», но вместо этого сломал хэндлер 404. Ещё один повод ночью всё-таки пытаться выспаться, а не шатать курисабу, да. Ближе к утру починил. >>49670 К 8:30 должно было уже быть починено, если до сих пор не починилось — то стоит почистить кэш (кэш клауды я в 15:30 сбросил). >>49817 >С сегодняшнего дня у меня в опере мини снова вместо капчи значок загрузки. Жесть. Так во всех тредах? В других браузерах не проявляется? В консоли оперы видны какие-нибудь сообщения?
WHERE 'parentid' = $threadid
WHERE 'parentid' = $threadid AND 'id' > $lastid
WHERE 'parentid' = $threadid AND 'timestamp' > $last_update
SELECT 'message' FROM ... WHERE 'parentid' = ... AND 'timestamp' > ...
$_REQUEST
$_REQUEST['json_data']
if (isset($_REQUEST['json_data'])) $_REQUEST = json_decode($_REQUEST['json_data'])
>>49833 > Жесть. > Так во всех тредах? > В других браузерах не проявляется? > В консоли оперы видны какие-нибудь сообщения? Ты не так понял. Не Опера, а Опера Мини, мобильный браузер, который грузит веб-страницы через прокси-сервера Оперы. Я через него с телефончика в интернете сижу. Да, во всех тредах.
>>49835 Ох, гоменнасай. Увидел «опера» и уже настроился на десктопную оперу, с которой у Курисача не очень радостные отношения (по крайней мере, были). После чистки кэша всё так же?
>>49837 В Опере Мини нет кэша. Может быть, он есть на прокси-серверах Оперы, но там я почистить не смогу.
>>49833> Или ты про то, что JSON в «голом» виде не передаётся?Именно. Используя xhr можно в голом виде, но из формы — никак. А передавать JSON в поле формы так вообще скрещивание ежа с ужом.> Как видно из моего поста (>>49609) — надо (к примеру, зависящая от типов данных сборка формы на javascript, если не использовать jQuery).Некоторые вообще не умеют не-вручную любые данные формировать, хоть формы, хоть JSON. Зато многие умеют делать это прозрачно, тогда как с JSON, определённо, почти никто.> Туда — список отображённых постов в треде, оттуда — новый список постов, обновлённая карта ответов и html-кусок для дописывания в конец треда.Если вы перейдёте на запрос по номерам, получится 2. Не понятно, к чему ты вообще про это сказал, если ни частным, ни общим запросом в 1 запрос ничего не выйдет.> Ну, как минимум, от сервера прилетает карта ответов в таком виде. От клиента тоже может понадобиться что-либо передавать.Сервер может что угодно передавать, давай не перескакивать на 20 шагов вперёд. Где клиенту потребуется передавать массив в массиве?> так и $_REQUEST['json_data'].Так ты серьёзно ежа с ужом скрестить собрался? Или пхп просто не умеет с другим форматом, отличным от форм, работать?> В многократных FormData::append().У нас jQuery используется, не надо никаких FormData и xhr. Голый JS вообще слабая штука.> Я больше чем уверен, что всё, что может отправлять формы, кроме специальных утилит, что только это и умеют, умеет работать и с JSON.Ну, вообще говоря — нет. > Я буду, например. Мне удобнее ссылку пастить в полеПри отправке скриптом добавляй содержимое поля в начало текста, делов то.> О святая Мадо-ками-сама! Да успокойся уже, будет тебе интерфейс с формами, если ты хочешь curl-ом читать Курисач.А ведь приходилось как-то.И зря ты его недооцениваешь. Через курл удобно потестировать запросы, чтобы разобраться, как они работают. И в случае с JSON это будет от неудобно в случае ежа и ужа до невозможно, если нормально делать. Хотя, может и возможно, лень проверять.
Тестировать надо автоматическими тестами phpunit и прочие, а не curl вручную. Да и json не бинарный, а текстовой, какие могут быть проблемы? Он парсится ничуть не медленнее формы, а уж маппятся они одинаково. Хотел было предложить вместо стандартного реквеста обертку из symfony, ну да ладно, кому как удобнее. Но вообще я согласен с хейтером жсон. Если вы не используюте RPC для всего, вплоть до формы загрузки, то зачем он нужен? Делайте API и все.
>>49666 >Который ни один браузер не поддерживает в формах, например. А при чем тут эти формы? Забудь ты про свои формы, что ты к ним привязался, это API. И все равно ответ-то в JSON придет. >можно курл использовать Ты еще скажи, что в curl нельзя использовать JSON, ага. http://stackoverflow.com/questions/7172784/how-to-post-json-data-with-curl-from-terminal-commandline-to-test-spring-rest Первая строчка в гугле. >>49851 >но из формы — никак. Зачем нам формы? >тогда как с JSON, определённо, почти никто И тут ты мне объясняешь, чего такого непрозрачного в кодировании JSON. >>49851 >Ну, вообще говоря — нет. Примеры? >Через курл удобно потестировать запросы, чтобы разобраться, как они работают. См. выше. >>49860 >Делайте API и все. Так его-то и делаем, на JSON. Просто один анон тут упорно пытается доказать, что JSON не нужен, а когда я ему говорю, что в API надо передавать список номеров постов для получения их содержимого, он начинает мне доказывать, что и это мне, видите ли, не нужно.
>>49840 Хм, то есть, подожди, она каждый раз всё грузит из инета, картинки там, всё-всё-всё? Очень странно, у меня даже в Opera Mobile на Windows Mobile 4 был кэш. >>49851 >А передавать JSON в поле формы так вообще скрещивание ежа с ужом. Почему JSON over HTTP POST — это «скрещивание ежа с ужом», а HTTP over TCP, TCP over IP, IP over Ethernet — нет? >Где клиенту потребуется передавать массив в массиве? Я уже говорил, что пока не знаю, но не считаю, что это нужно запретить пользователю. >Или пхп просто не умеет с другим форматом, отличным от форм, работать? Хм, а интересная идея — пытаться сначала парсить поле формы как json, потом запрос как форму (через $_REQUEST), и наконец, если это не удалось — то php://input как json. Надо будет тоже заложить такую возможность. >У нас jQuery используется А у клиента может и не использоваться. >При отправке скриптом добавляй содержимое поля в начало текста, делов то. Это был один из вариантов, что я рассматривал — но он не был связан с отключением функциональности, в отличие от изначально предложенного тобой. >А ведь приходилось как-то. А месье знает толк в извращениях. Поясняю: я имею в виду не «проверить какую-то фичу и посмотреть что в запросе, что в ответе» — там, действительно, нужна максимальная простота тулзов. Я имею в виду читать в нормальном виде. >И зря ты его недооцениваешь. Я юзаю curl тогда, когда именно он нужен, а не вместо браузера. Для отладки он порой незаменим, а вот в нормальном режиме я лучше посижу через Хоро, например. >Через курл удобно потестировать запросы, чтобы разобраться, как они работают. Именно >до невозможно, если нормально делать. Как Гин пишет ниже — возможно. >>49860 >Если вы не используюте RPC для всего, вплоть до формы загрузки, то зачем он нужен? Банальная простота упаковки и распаковки клиентом и сервером.
php://input
>>49971 > у меня даже в Opera Mobile на Windows Mobile 4 был кэш Opera Mobile и Opera Mini — совершенно разные браузеры. > она каждый раз всё грузит из инета, картинки там, всё-всё-всё? Весь трафик проходит через прокси-сервера Оперы, где веб-страницы переформатируются и сжимаются. Любые запросы, скрипты — всё выполняется через сервера. Конечное устройство только отображает статичную страничку, загружая каждый раз новую после любого обращения к серверу. В общем, раньше при переформатировании страницы Курисача на прокси-сервере Оперы в итоговую страничку, передаваемую мне в телефончик, на место капчи ставилась картинка с капчей, а теперь — значок загрузки. Капча сейчас, как я вижу, не сразу выдаётся, а подгружается после загрузки страницы. Возможно, дело в этом. Два дня назад капча выдавалась так же?
>>49982 >Два дня назад капча выдавалась так же? Да, в том-то и дело. По окончании загрузки вызывается функция refreshCaptcha() и заменяет этот значок загрузки на сгенерированную капчу. Причём, в обычной опере и в хроме в некоторых тредах тоже такое было, но после небольшого шаманства (несколько месяцев назад) с тем, где вызывать функцию refreshCaptcha() (перенёс просто в код страницы из $(document).ready) проблема решилась. В Opera Mini, судя по всему, консоли тоже нет, да?
>>49863> Ты еще скажи, что в curl нельзя использовать JSON, ага.Не был уверен насчёт кастомизации формата. Однако JSON ещё и ручками вбивать надо. Пипец удобно.> Примеры?Курл как раз, но это я поздно. Я вообще мало HTTP клиентов знаю, чтобы кучу примеров приводить, но и его утверждение ни разу не доказано.> он начинает мне доказывать, что и это мне, видите ли, не нужно.Но ведь и правда не нужно. Где тебе оно нужно ты так и не рассказала.>>49971> Почему JSON over HTTP POST — это «скрещивание ежа с ужом», а HTTP over TCP, TCP over IP, IP over Ethernet — нет?Скрещивание это когда ты JSON кодируешь в поле формы, а не отправляешь в чистом виде.До чего забавно, вы так хотите этот JSON и имеете разные представления о том, как его надо передавать. Это так, к слову.> Я уже говорил, что пока не знаю, но не считаю, что это нужно запретить пользователю.Не надо сюда снова приплетать свой линукс вей, пожалуйста. Это уже выглядит как простое оправдание своей лени подумать.> А у клиента может и не использоваться.Что? Тогда сайт работать не будет, тут куча всего jQuery использует.> Как Гин пишет ниже — возможно.Возможно, но не нормально.
>>50013 >Однако JSON ещё и ручками вбивать надо. Данные в любом случае придется вбивать руками, будь то форма, будь то JSON. Даже если брать из файла, то все равно в файл надо будет вбивать руками. >Где тебе оно нужно ты так и не рассказала. Да я уже десять раз разъяснила про обновление. >спойлер Наверное потому, что у Хомуры php, а у меня python. На самом деле, разница между формой и json в питоне такова: форма: payload = {'field1': nujno, 'field2': toje_nujno} r = requests.post(url, data=payload) а json: payload = {'key1': nujno, 'key2': toje_nujno} r = requests.post(url, json=payload) Потому какой-то сложности в использовании json вообще не вижу. >Тогда сайт работать не будет, тут куча всего jQuery использует. Ну всякие дашчаны и прочие обходятся ведь без jQuery спокойно.
payload = {'field1': nujno, 'field2': toje_nujno}
r = requests.post(url, data=payload)
payload = {'key1': nujno, 'key2': toje_nujno}
r = requests.post(url, json=payload)
>>50021> Данные в любом случае придется вбивать руками, будь то форма, будь то JSON. Даже если брать из файла, то все равно в файл надо будет вбивать руками.Вот только форму вбивать гораздо проще, просто несравнимо.> Да я уже десять раз разъяснила про обновление.Для которого достаточно частного запроса. На этом список, видимо, заканчивается.> Ну всякие дашчаны и прочие обходятся ведь без jQuery спокойно.Мы вообще-то про JS до этого говорили. Если клиент (браузер) из-за каких-то нелепых побуждений юзера блокирует jQuery (через адблок, например), то сайт не будет нормально работать.
>>50013 >Однако JSON ещё и ручками вбивать надо. А форму разве нет? >но и его утверждение ни разу не доказано. У меня было не утверждение, а догадка, основанная на впечатлении от известного мне ПО. >спойлер О передаче его не в виде поля формы и возможности удобного распарсивания на php я узнал, пожалуй, только пару дней назад. Мне-то без разницы, как мне его передадут, я смогу схватить данные любым из этих трёх способов. >оправдание своей лени подумать. >лень >запилить три способа работы на выбор вместо одного У меня какое-то не такое представление о лени? >Тогда сайт работать не будет Я про абстрактный клиент на JS, не связанный с сайтом. Естественно, это гипотетический случай, и я его привёл как один из способов создания форм, который я знаю. Суть в демонстрации факта, что есть ситуации, в которых json делается проще, чем форма. >>50038 >Вот только форму вбивать гораздо проще, просто несравнимо. Ставить знаки равенства намного проще, чем двоеточия?
>>50097> У меня какое-то не такое представление о лени?Программирование — техника. Ты просто садишься и пишешь простой код как умеешь тем более когда дело касается простенького сайт на пхп, это больше «пролетарская» работа, вроде работы за станком. Тебе может не лень этим заняться. Включить голову и хорошо подумать, зачем ты что-либо делаешь, безусловно, сложнее, и тут уже включается лень.> есть ситуации, в которых json делается проще, чем форма.Конечно есть. JSON происходит от JS вот это поворот, который умел работать с ним с момента его создания.В общем-то, наличие таких ситуаций мало чего доказывает.> Ставить знаки равенства намного проще, чем двоеточия?А ещё скобки (как минимум 2), запятые, кавычки (ключи и строки).
Не знаю куда идти, спрошу здесь. Почему .онион ссылки через тор не открывает?
