как передать инфу js->php->js не через файл?
- Войдите на сайт для отправки комментариев
Пт, 01/11/2019 - 22:12
Привет, all.
Имеем: два клиента - компуктор с js-приложением, и нерутованный (всмысле на котором выполнять bind(), connect() и accept() запрещено операционной системой) телефон. Надо с телефона управлять компом. Посередине схемы (на том же компе) стоит openserver.
Существует ли способ заставить один и тот же php сценарий помнить, что он делал в прошлых своих запусках, не записывая файл? Ибо если телефонов и компов будет 500, то сервер превратится в убийцу винтов.
Как временный костыль знаю RAM disk, но интересно, возможно ли обойтись без него.
UPD, в первом посте ошибка, ессно вместо слова "connect" читать "listen"
UPD2, вроде нашлось. Для интересующихся: https://github.com/google/pywebsocket
Что мешало использовать субд для «памяти о былом»?
В генерализованном решении без записи в долговременную память не обойтись. В данном конкретном без схемы ничего непонятно - кто что и где должен хранить и как тут замешан дворецк... js-скрипт.
Был бы там http, я предложил бы ставить куки. Впрочем и JS может при обращении к PHP-скрипту что-то из куки засылать.
Так пишет решено. Из JS через WebSocket на сервер к апаче ходит. А хранить чего современный JS и без кукисов умеет, один SQLite - моща.
Как будто sqlite - это "не записывая файл".
Вопрос был в том, как серверную часть избавить от писания на какой-либо носитель. А это - или лупить в mmap или перенести импакт на клиентов. Первое будет терять данные на ребуте, второе - нет. Но, так как от задачи видны только уши, то и совет будет на уровне "а может аспирином полечить?"
//Вопрос был в том, как серверную часть избавить от писания на какой-либо носитель.
Вы не поняли проблемы. 500 записей в файл на сервере - плохо, 500 записей на 500 разных устройствах, и соответственно в 500 файлов - ОК.
Ну БД и файл - несколько разные сущности и по большому счету куда там СУБД пишет с клиента (может прямо в облако) нам мало дела. Главное не на сервер, по условию задачи. А то что в ИТ данные как правило в файлах - тут Вы правы. Это как бы не обсуждается, по крайней мере если сервер иногда ребутят и потери не допустимы. Факт что JS может сохранять БД на клиенте и имеет нормальный канал на сервер к апаче и следовательно "перенести импакт на клиентов" становится отличным решением. К примеру так, отправку SQL запроса из пыхи клиенту к его БД, и возврат выборки в пыху, я думаю ценители оценят ;) И все это асинхронно, без перепаковок в JSON (хотя конечно желающие - могут и JSON юзать) и мегабайт сторонних глюков в библиотеках. Ну а кому то конечно только уши видны.