ExBB Community ExBB Community
 Сайт проекта ExBB Общение объединяет!
Войдите на форум при помощиВойти через loginza
 Чат на форуме      Помощь      Поиск      Пользователи     BanList BanList

Страниц (13): В начало « ... 2 3 4 5 [6] 7 8 9 10 ... » В конец

> Найдено сообщений: 186
Flat Отправлено: 26 января 2019 — 13:27 • Тема: Мод: Текстовое подтверждение при регистрации • Форум: Модификации и дополнения

Ответов: 97
Просмотров: 89389
Yamaliya пишет:
Сделали что-то толковое? Покажите нам, оценим.
Просто поболтать зашли?

Yamaliya , честно говоря, я зашёл чтобы напомнить о существовании других, более дружелюбных пользователям путей.
Что касается того, что сделано, то долго вообще ничего не программировал в связи с психологическими проблемами, отсутствием мотивации и пр. Сейчас пришёл в норму и продолжаю делать форум практически с нуля. Регистрацию практически сделал. Точка входа через индексный файл. Много функций уже сделал. Общая структура форума определилась. Сделал активацию через мыло для подтверждения, но выкинул этот уже готовый модуль, оставив только регистрацию. На это есть определённые причины. Позже обьясню подробней. Сейчас всё идёт как по маслу. Раз уж взялся за гуж не говори, что не дюж.
Модули подключаются через общий список, поэтому злоупотреблений не будет.
Очень долго тестирование занимает, зато теперь вся регистрация, работает как часики. Файлы забаненых логинов, запрещённых слов при регистрации, статистики коонференции заполняются, а если какой-то служебный файл потеряется, то скрипт автоматически его создаёт на прежнем месте, так что админу облегчение. Ещё немного и практически готовое ядро будет, где можно будет создавать сообщения.
Скрытое поле у меня сделано так(можно переделать):
в шаблоне прописывается поле для ввода, в данном случае второго поля для пароля:
CODE:
<tr>
<td class="profilleft">
<b>
Пароль
</b><br />
<span class="desc">
Введите пароль. Имейте ввиду, что все пароли чувствительны к регистру. Можно использовать только такие символы: от a до z, от A до Z, и цифры. Минимум <b>8</b>, максимум <b>30</b> символов!
</span><br><br>
<input type="text" size="20" name="password1" maxlength="30">
</td>
</tr>

<tr id="hd">
<td class="profilleft">
<span class="desc">
Подтвердите пароль.
</span><br><br>
<input type="text" size="20" name="password2" maxlength="30">
</td>
</tr>


В файле css делаем запись:
CODE:
#hd { display: none; }

поэтому его не видно при регистрации.
зато видно боту.
В скрипте проверяем заполнено это поле или нет:
CODE:
if(!empty($_POST['password2']))
exit('Access denied!');

если заполнено, то выходим из скрипта с сообщением, хотя это и не обязательно.
Yamaliya , сейчас выкладываь весь код смысла нет.
(Добавление)
Yamaliya , вот практически готовый рабочий модуль регистрации тысячу раз протестированный Привожу чтобы вы имели представление что такое мой собственный дилетантский код:
Регистрация (Отобразить)
Flat Отправлено: 26 января 2019 — 11:39 • Тема: Мод: Текстовое подтверждение при регистрации • Форум: Модификации и дополнения

Ответов: 97
Просмотров: 89389
А я делаю так, что юзерам вообще ничего вводить не придётся в том числе каптчу. О проблемах с каптчами что только не написано. Просто делаю скрытое поле для ввода(оно может быть любым). Бот обязательно его заполнит, что проверяется и если заполнено даём отворот поворот. Ну, а против людей-ботов ничего не поможет..
думаю, не нужно грузить пользователей дополнительными обязанностями. Всё надо делать скрыто силами самого скрипта.
Flat Отправлено: 25 января 2019 — 07:17 • Тема: Отправить письмо администратору сайта • Форум: Обсуждение

Ответов: 61
Просмотров: 26389
Parapsixolog пишет:
Одним словом без почты ни как нельзя.

Вот вы написали, что никак нельзя, а сами пишите, что этими фичами практически не пользуетесь..
Массовая рассылка сейчас проблема, ибо все почтовые сервисы очень подозрительно к ней относятся.
Восстановление пароля, то есть генерация нового и отправка его на мыло, тоже проблема, ибо:
1) пароль летит по сети в открытом виде.
2) на почте пользователя хранится в открытом виде.
3) индетификация пользователя только по его почтовому адресу, а не по паролю, может привести к нежелательным атакам. И эта проблема на мой взгляд ещё не полностью решена в данном движке.

Честно говоря я против восстановления паролей из-за проблем с безопасностью. Знаю одного человека на одном форуме, которого банили 5-6 раз и регался под новым ником снова и снова. И все прекрасно знали кто пишет, так как стилистика текстов одна и та же. Под каждым ником у него было несколько тысяч сообщений. И все прекрасно жили и живут.Скажите мне: зачем восстанавливать свой профиль, если человек потерял свой пароль? Если человек знает, что всегда может восстановить свой профиль, то никогда не будет бережно относиться к хранению своего пароля. Он его будет постоянно забывать. а если он знает, что при потере пароля восстановить его не удастся, и ему придётся регистрироваться под новым логином, то будет хранить его как зеницу ока. Мы сами своими руками развращаем юзеров, при этом теряя в безопасности.
Ну, нельзя полагаться только на почтовый адрес юзера для того, чтобы его точно идентифицировать. По разным причинам. Данный форум уже ломали через восстановление, не помните?
На мой сугубо личный взгляд, который никому не навязываю, форумный движок должен быть полностью автономным. он должен быть закрыт от внешнего мира полностью. Он должен позволять юзерам определённые действия, но не выпускать их за рамки дозволенного. Почта должна быть только внутри движка и точка. Внешние ссылки должны быть только текстовые. Сейчас любой браузер позволяет по текстовой ссылке перейти на любой сайт, при этом никаких xss атак не будет.
Так я это вижу, и так делаю для себя. Если кто не согласен со мной то есть туева куча универсальных движков с сотнями разрабов и сотнями багов и уязвимостей, то им туда.
Flat Отправлено: 21 января 2019 — 07:55 • Тема: Теперь тута, ну и для отметки кто пришел, и кто потерялся • Форум: О жизни

Ответов: 246
Просмотров: 140963
никто не занимается вот и не видит.
Только сейчас заметил внизу страницы:
Цитата:
Parse error: syntax error, unexpected $end in /home/exbb/exbb.info/www/community/include/page_tail.php on line 75

Обычно вверху вылазит, а тут внизу. Не закрыты ни </html> ни </body>, а раньше были.
И в коде элемента в браузере опера такой нотис:
Цитата:
Failed to load resource: http://exbb.info/community/templ...xBB/tile_sub.gif the server responded with a status of 404 (Not Found)

Видимо при переезде потерялся файлик.
Flat Отправлено: 20 января 2019 — 07:16 • Тема: Теперь тута, ну и для отметки кто пришел, и кто потерялся • Форум: О жизни

Ответов: 246
Просмотров: 140963
У меня всё в порядке. Никаких нотисов не вылезает, ничего не тормозит, захожу почти каждый день. Но я сейчас на windows xp, хотя есть машинка с win 10. На xp как-то приятней.
Flat Отправлено: 31 декабря 2018 — 07:15 • Тема: С наступающим новым годом! • Форум: О жизни

Ответов: 7
Просмотров: 4228
С наступающим всех Новым Годом! Желаю всем оставаться приверженцами плоских файлов и в новом году! Всем лёгкого бэкапа!
Будем продолжать развитие!
Flat Отправлено: 17 декабря 2018 — 09:13 • Тема: Размышлизмы о движке • Форум: О жизни

Ответов: 64
Просмотров: 33345
Sigurni пишет:
Примеры, что конкретно неправильно?

1. Не нужно было размазывать по разным функциям открытие-закрытие файла. Да ещё делать массив для хендлов файлов. Бред отборный. Элементарно можно забыть закрыть файл через тонну кода. Правильней делать это всего-лишь в одной функции.
2. Функция _Read2Write читает файл с исключительной блокировкой. Это не правильно, ещё раз повторю для непонятливых.
Оно вроде как работает, но в один прекрасный момент...
Sigurni пишет:
Ага, т.е. вам мало написать своё некое подобие СУБД, вы собираетесь к ней ещё и некое подобие phpMyAdmin делать? И сколько лет это займёт?

Я писал, что могу это сделать при необходимости. однако в планах на конкретный движок у меня этого нет. Я делаю упрощённый вариант. Кстати, я тут недавно написал, что беру старую версию и т.п. Не верьте мне. Более вникнул в код старой, там куча мала того что мне не нравится. Сейчас я продолжаю работать над совершенно самостоятельной версией. Т.е. там будет только мой нативный код. Иногда будет проскальзывать общая структура некоторых файлов из существующих версий, однако в целом код полностью переписан с нуля. Много добавлено и много убрано. Мне лично нравится. Вчера делал например обработку формы регистрации. Сегодня делаю обработку формы активации по ключу. Короче говоря занимаюсь регистрацией. В существующем движке регистрация сделана несколько кривовато. Проскальзывают ошибки и баги. Например нашёл такой баг по ходу изучения кода: в exbb не обрабатываются символы Ё и ё вобработчике формы регистрации, по крайней мере в кодировке 1251. Я у себя исправил этот баг. Ну и далее по мелочи много чего.
Sigurni пишет:
Возьмите и добавьте запись в начало файла. Вы получите полную перезапись. Байки про "запись на старое место" даже не знаю, откуда вы берёте. Такая запись возможна, если вы работаете с файловой системой напрямую, на уровне её драйвера или ядра ОС.

Почему же? Если открывать файл со спецификатором w то перезапись может быть где угодно, а если с r+ то будет писаться на старое. Я проводил эксперименты по перезаписи, это не фантазии. Можете проверить сами.
Sigurni пишет:
Ваше решение с tmp-файлами годится разве что для создания бекапов файлов, но никак ни для рядовой работы с ними, т.к. при перемещении/переименовании файлов сразу слетит установленная ранее блокировка, и вам нужно будет использовать другой механизм синхронизации процессов для предотвращения повреждения данных.

Вот это меня тоже насторожило. Поэтому я и отказался от этого переделав функцию. Но как пишут в реальности всё работает..
Sigurni пишет:
Судя по вашему коду

Мой код прекрасен(для меня) Более того: я его люблю. А во на оопнутый код смотреть не могу. Для меня он быдлокод.
Sigurni пишет:
При этом своего толкового (и главное рабочего) вы так до сих пор ничего и не предложили. Я считаю, что стоит с пониманием и уважением относиться к чужому труду, тем более что ваша работа всё равно так или иначе на нём основывается.

Проблема в том, что я раскидываюсь по сторонам. Сейчас начал более времени посвящать этому, так что возможно скоро будет рабочая вещица..
Sigurni пишет:
А с вашими функциями, где фигурируют числовые ключи, работать будет крайне неудобно, вы сами это поймёте, когда перейдёте от ядра к функционалу.

Ещё добавлю, почему это нужно. В файлы подобного формата информацию можно добавлять со спецификатором a или a+. Это позволяет не беспокоится за основное тело файла, ибо оно не перезаписывается, как это происходит когда приходится сохранять целый сериализированный массив. Поэтому для меня это веское соображение в пользу таких файлов, на чём я и остановился.
Flat Отправлено: 12 декабря 2018 — 11:33 • Тема: Размышлизмы о движке • Форум: О жизни

Ответов: 64
Просмотров: 33345
Sigurni пишет:
В этот момент вы должны читать именно с исключительной блокировкой, что и сделано в ExBB.

Неверно сделано. _Read более менее нормально сделали, а с _Read2Write так не получилось. Из старой версии рожки растут.
Sigurni пишет:
файловый архив студентов

Прекрасная лаба. там всё верно.
Sigurni пишет:
ваши палочки - |) и подсчитывая по индексу, что означает то или иное поле.

Так и я могу сделать отображение в приемлемом виде в админке. Не вопрос.
Только и так всё понятно, и кж понятней чем сериализированные данные.
Sigurni пишет:
Если бы вам нужен был форум, вы бы давно уже поставили его.

Да я что только не ставил..
Sigurni пишет:
С вашими же файлами, если питание пропадёт аккурат на работе fwrite (например), то файл окажется битым, и пока пользователь вручную исправит его, нормальная работы с ним будет невозможна.

Давайте про mysql не будем, меня это вообще не интересует, честно.
Ошибаетесь. Предложенная реализация подразумевает запись на старое место, и в коде движка будут предприняты все меры для того, чтобы размер файла при перезаписи сохранялся, исключением те файлы в которых записи редактируются. При добавлении потери не будет в принципе, так как старый файл сохраняется на своём старом месте. При перезаписи к примеру нескольких полей, таких как время последнего посещения можно сохранять длину записи и писать поверх старых данных. В этом случае, даже если сервер грохнется то весь файл останется цел, за исключением возможно повреждённой этой записи, и то не факт.
Что касается редактирования, то тут, конечно риск есть, но тут можно вернутся к темп файлу конкретно для данного случая. Редактируются файлы прямо скажем не часто.
Sigurni пишет:
Дискриминировали устаревших динозавров.

Не надо разводить священные войны. Это вопрос религии.
Я достаточно знаю, чтобы судить что такое ООП на самом деле.
Sigurni пишет:
Открою вам секрет: обычные пользователи в файлы вообще не заглядывают. Они смотрят на функционал и оформление.

С этим будет получше. Один только вывод сообщений чего стоит: со времён дос наверно.
Обычные пользователи сидят на других движках. А на подобных этому сидят в основном те, кто хочет покопаться своими ручками. Жигули и мерседес: в одном сами копаются, а другой отдают в сервис-центр. Каждому своё. Мне нравится всё держать под собственным контролем.
Sigurni пишет:
Бедный http://imho.ws, работает уже 15 лет

Он ещё не набрал критическую массу..
Sigurni пишет:
Эй, все слышали? Налетай-торопись! И как мы раньше жили без версии 10-летней с правками в представлении от Flat! Переименуем функции, слегка изменим файлы и тогда-то уж точно заживём!

Во-первых, повторяю: делаю исключительно для себя, так как нужно лично мне. А другие могут использовать то, что я наваял если захотят.
Во-вторых, я считаю, что код старой версии был испорчен, и испорчен был сознательно. О причинах умолчим..
Да, некоторые вещи исправили, но заложили много подводных камней.
Я уже говорил, что эволюцию старого движка надо было продолжить в том же ключе, исправив мелкие недочёты, может быть кое что изменив. Однако этого не произошло. А те, кто продолжал заниматься старой версией даже не удосужились исправить тот основной баг с обнуление файлов, которые были практически у каждого кто пользовался тем движком. А движок то был хороший, простой и понятный.
Flat Отправлено: 12 декабря 2018 — 07:56 • Тема: Размышлизмы о движке • Форум: О жизни

Ответов: 64
Просмотров: 33345
Sigurni пишет:
При работе с записью нужно использовать не разделяемую, а исключительную блокировку. И да, даже когда читаете из файла.

Не нужно. Доки почитайте.
Цитата:
Разделяемая блокировка

Мы решили ровно половину нашей задачи. Действительно, теперь данные из нескольких процессов-писателей не будут перемешиваться, но как быть с читателями? А вдруг процесс-читатель захочет прочитать как раз из того места, куда пишет процесс-писатель? В этом случае он, очевидно, получит "половинчатые" данные. То есть, данные неверные. Как же быть?

Существуют два метода обхода этой проблемы. Первый — это использовать все ту же исключительную блокировку. Действительно, кто сказал, что исключительную блокировку можно применять только в процессах, изменяющих файл? Ведь функция flock() не знает, что будет выполнено с файлом, для которого она вызвана. Однако этот метод довольно-таки неудачен, и вот по какой причине. Представьте, что процессов-читателей много, а писателей — мало, и к тому же писатели еще и вызываются, скажем, раз в пару минут, а не постоянно, как читатели. В случае использования исключительной блокировки для процессов-читателей, довольно интенсивно обращающихся к файлу, мы очень скоро получим целый их рой, висящий, недовольно гудя, в очереди, пока очередному процессу разрешат читать. Но ведь никакой "аварии" не случится, если один и тот же файл будут читать и сразу все процессы этого роя, правда? Ведь чтение из файла его не изменяет. Итак, предоставив исключительную блокировку для читателей, мы потенциально получаем проблемы с производительностью, перерастающие в катастрофу, когда процессов-читателей становится больше некоторого определенного порога.

Отсюда
Sigurni пишет:
Аргументируйте, что тут небезопасно.

Почитайте ветку где обсуждались проблемы и их лечение и сравните с кодом в дистрибутиве.
Sigurni пишет:
Так там нет по сути никакого ООП. Всего несколько системных классов, которые на самом деле работают как пекеджи/неймспейсы для функций, а не полноценные объектные сущности.

Дык я об этом с самого начала писал: http://exbb.info/community/topic...13312#1531213312
Вопрос только в том, зачем это надо было делать?
Sigurni пишет:
Про "бабки" вообще смешно читать. Вам надо не функции, а комедийные детективы писать.

Это уж не вам решать.
Sigurni пишет:
Современные СУБД шагнули уже далеко вперёд. Возьмите тот же MySQL, новые решения на его базе (MariaDB/Percona Server) показывают прекрасную производительность для задач форума. А если задействовать кеширующие решения типа memcached, а может и что по-мощнее...

Флаг в руки: переходите на дб. Таких движков куча. Что же вы делаете здесь на форуме, который посвящён исключительно файловой версии? Многим, очень многим работа с дб просто не нужная головная боль, поэтому и применяют простые файловые движки, неужели не понятно?
Sigurni пишет:
Те 4 человека, что остались здесь?

Сюда однако заходят не 4 человека, а десятки посетителей за день, посмотрите статистику. И многие форумы на этом движке до сих пор живут и здравствуют. И мне лично движок с базой не нужен, хотя я как программист-любитель и понимаю язык запросов и мне не сложно будет например перевести с одного хостинга на другой, чай, из детских штанишек уже вырос. Но вот как другим быть, которые не знают язык mysql? А таких много, а я знаю случаи, когда даже опытные в этом деле товарищи, которые держат свои форумы на mysql теряли половину своих данных из-за элементарных ошибок при конвертации и т.п вещей.. Мне такой геморр не нужен. А если вам нужен повторяю: флаг в руки переходите на phpbb или другой подобный движок.
Sigurni пишет:
Вот была же хорошая мысль, но...

Во первых, для работы с sqlite нужно работать через ООП-обёртки, так как sqlite-3 не поддерживается в процедурном стиле. Или через PDO драйвер, что тоже самое по сути. Но это так, инфо к размышлению. Просто дискриминировали процедурщиков.
Во-вторых, опять же в таком случае нужно создавать новый движок с нуля. Вопрос времени. В одиночку это сделать нужно минимум 2 года. У меня их нет.
В-третьих, файловый движок должен быть файловым от начала до самого конца. Файловая система по сути сама есть определённого типа дб.
Если делать свою реализацию, файлы с дб будут ещё нечитаемей чем нынешнии сериализированные, причём малейшее изменение файла может угробить всю базу. Поэтому файловая система намного надёжнее.
Даже в платных навороченных движках базы начинают сыпаться при определённом числе записей. Возможно что это баги в самом mysql, очём много писано. Даже в вобле форумы глючат не по детски. И зачем мне это нужно?
Я сейчас беру последнюю безоопную версию, и начинаю править код под то представление о нём, которое есть у меня. Старая ветка будет продолжена!
Ждите новую версию движка!
Flat Отправлено: 11 декабря 2018 — 12:11 • Тема: Размышлизмы о движке • Форум: О жизни

Ответов: 64
Просмотров: 33345
1Bot пишет:
У Вас тоже кода с прямым доступом к файлам до сих пор нет.

У меня были варианты такого кода. много экспериментировал. Но всё это настолько сложно, что легче, гораздо легче просто использовать sqlite. А мне бы не хотелось именно в данном движке что-то кардинально менять. Сейчас уже многие движки работают с sqlite. А лучше мы всё равно не сделаем. sqlite классная штука, те кто в курсе.
Файловый движок тем и уникален, что работает на файлах, и занимает свою нишу. От этого уходить нельзя, поэтому я и прекратил заниматься фи..ёй..
1Bot пишет:
существенно так и не продвинулось дело.

Смотря в какую сторону..
В данном движке пошли на усложнение, хотя надо было не переписывать всё, а брать тот старый и просто напросто вылизать код, устранив некоторые баги, и добавив функционала. А теперь куда ушли? Мне лично не нравится в какую сторону уехал код с появлением 2 версии..
Flat Отправлено: 11 декабря 2018 — 06:55 • Тема: Размышлизмы о движке • Форум: О жизни

Ответов: 64
Просмотров: 33345
Почитал так недавно старый форум, на котором обсуждали старые версии движка(ещё не оопнутого). Там одна проблема была это обнуление файлов. Сейчас эта проблема исправлена. Я посмотрел код старой версии и нашёл этот баг. К сожалению те ребята не смогли это увидеть в своё время. А когда форум разделился, на данном усиленно начали доказывать, что те версии небезопасны. Дык и данная версия небезопасна ибо много уже исправленных проблем просто не вошло в дистрибутив. Однако та версия была гораздо проще, код яснее, почему бы ещё тгда не исправить несколько ошибок? По всей видимости кое-кто решил срубить бабок на этом деле.. Ну, ну..
Flat Отправлено: 9 декабря 2018 — 17:23 • Тема: Размышлизмы о движке • Форум: О жизни

Ответов: 64
Просмотров: 33345
Flat пишет:
Такая система применяется многими с успехом и ещё не было нареканий, могу привести некоторые ссылки. например:

Сейчас всё намного упростил. Отказался от темп файлов. Для юникс серверов это ненужно потому что флок там работает нормально. А вот для виндовс серверов надо делать отдельную реализацию.
Функция sibb_fput (Отобразить)

Также заменил функции file() на собственную реализацию. Оказывается она не использует разделяемую блокировку. Теперь всё ok
Flat Отправлено: 9 декабря 2018 — 14:26 • Тема: Размышлизмы о движке • Форум: О жизни

Ответов: 64
Просмотров: 33345
Yamaliya пишет:
что то навеяло

Да, вы правы. Вместо этих излишних дискуссий я лучше бы накалякал столько же строк кода..
Flat Отправлено: 8 декабря 2018 — 10:08 • Тема: Размышлизмы о движке • Форум: О жизни

Ответов: 64
Просмотров: 33345
Вышеприведённый код скопирован мной с пробного файла, а не с готового, по ошибке, поэтому содержит несколько явных ошибок. То есть я уже давно это переделал. Хотя принцип прежний остался.
Sigurni пишет:
и даже без "отключения питания сервера" (очень повеселила эта фраза).

Хорошо, повеселимся вместе..
Sigurni пишет:
Т.к. изменения, внесённые пользователем A, находятся ещё только в ОЗУ, пользователь B получает старые данные (без учёта изменений пользователя A). В результате мы получаем состояние гонки процессов, и изменения того пользователя, процесс которого первым выполнит fwrite, будут безвозвратно утеряны.

Sigurni , вы думаете, что я не учитывал существование процессов на апаче?..
По первому пункту.
Я одного не могу понять: каким образом в данном случае будут потеряны данные одного из пользователей? Во-первых каждый пользователь пишет в собственный файл(смотри код данного движка, у меня также), поэтом в принципе не может быть ситуации "потери бойца". Во-вторых, даже при записи в общую структуру, такая ситуация просто не возможна, ибо на момент записи файл "флокается", то бишь запирается для любых процессов. Но, предположим по вашей логике, что в ОЗУ находится два-три-четыре (сколько угодно)копии структуры, с разными изменениями. Даже в этом случае каждый процесс будет ожидать своей очереди (в функции flock) на запись или чтение.
Sigurni пишет:
В этот момент (аккурат до вызова flock) приходит пользователь B и начинает читать массив,

Такого не может быть, ибо читает массив из файла он опять же после вызова функции flock и никак иначе. А в внутри этой функции если что ожидает своей очереди.
И о какой такой "гонке процессов" вы говорите: действительно не пойму. Просветите пожалуйста.
Теперь по второму пункту.
Sigurni пишет:
Его процесс ничего не знает про то, что процессом пользователя A создан tmp-файл, уже с новым сообщением, и читает старый файл (не tmp), где этого сообщения нет. Тем временем процесс пользователя A закончил работу с tmp-файлом и вызывает rename. Тоже самое спустя некоторое время сделает процесс пользователя B. В результате, сообщение пользователя A будет утеряно.

Опять: обьясните каким образом будет утеряно сообщение пользователя, если каждый процесс создаёт собственный ОТДЕЛЬНЫЙ временный файл с уникальным именем? Такая система применяется многими с успехом и ещё не было нареканий, могу привести некоторые ссылки. например: http://chelnavka.ru/members/page..._M__quickjump__N
Sigurni пишет:
Не нужно изобретать велосипед и пытаться написать на скриптовом языке то, для чего он не предназначен. PHP не предназначен для написания СУБД.

А я разве написал СУБД? Были правда у меня попытки это сделать но я от этого отказался, во всяком случае в этом движке. А другие реализации успешно применялись и работали стабильно на чистом пыхе, опять же могу ссылки кинуть.
Это чисто работа с файлами, это не субд.
Вы видимо плохо ознакомились с кодом и принципом записи в файл в данном движке, а он практически мало отличается от моего, за исключением некоторых важных моментов. Он тоже файловый, если вы ещё не успели заметить.
Sigurni пишет:
Даже текущая версия ExBB, пусть и файловая, хотя бы работает на базе встроенных функций serialize/unserialize, которые, будучи написаны на C, работают на порядок быстрее даже самых оптимизированных PHP-аналогов

А это уже откровенный бред. Даже комментить не хочется.. Функция file например на порядок быстрее serialize и тоже реализована на Си, как и всё в PHP. Я лично проводил бенчмарки. Можете сами убедится.
Sigurni пишет:
И функционал, которые эти функции предоставляют, на порядок выше того, что у вас. В частности, можно сохранять ключи, многомерные массивы.

А вы там не заметили функции var_export? Она делает то же самое: сохраняет любой обьект, в том числе массивы. Просто так сохраняются у меня только внутренние структуры, например конфиги. А пользовательские данные сохраняются в более приемлемом виде, благодаря чему можно избавится от ненужно мусора и не занимать лишнее место на сервере, а это деньги.
Да и не правильно по большому счёту сохранять многомерные массивы в таком виде. В реляционных моделях в таких случаях делают отдельную таблицу, а не пытаются сделать массив массивов-массивов и т.д. Это бред.
Sigurni пишет:
А с вашими функциями, где фигурируют числовые ключи, работать будет крайне неудобно, вы сами это поймёте, когда перейдёте от ядра к функционалу.

Я всё понимаю даже лучше вас, так как уже десятки вариантов перепробовал и говорю по опыту а не из головы. Я не теоретик, а практик. Числовые ключи при наличии документации не проблема. У меня на каждый такой файл есть документ, где прописаны что каждый ключ обозначает. Также это позволяет убыстрить код. Кому нужно тот всё поймёт. А постоянно держать строковые ключи ради того, что когда-то кто-то там не сможет разобраться это просто засорять код.
Sigurni пишет:
Вы считаете несколько легковесных дополнительных операций (да и то на C), как накладных расходов от ООП в PHP, серьёзной ошибкой

Не только я так считаю. И дело тут не просто в накладных расходах(по памяти например), а в том что первоначально язык создавался для НЕПРОФЕССИОНАЛОВ. Почитайте историю его создания. Для создания простых cgi приложений. Только по недоразумению он перерос самого себя и стал трендом, поэтому нужно было быть "как все"..
Sigurni пишет:
и при этом замахиваетесь на написание собственной СУБД

В данном движке, который я делаю, субд не будет. Однако эксперименты, которые я делал говорят о том, что эффективность такой реализации была бы не ниже mysql.
Sigurni пишет:
Имхо, вместо того, чтобы быть велосипедистом, стоит просто подучить ООП (а не отрицать его) и работу с полноценными СУБД, в том числе NoSQL.

Я читал много книжек про ООП, даже такие, которые вы в глаза не видели и знаю как работают с ооп в пыхе. Могу наворотить такого что уши в трубочку свернутся и не только у меня.. Но я ПРИНЦИПИАЛЬНО не использую сию методику, которая на мой взгляд губит всю индустрию ПО на корню. И использовать не буду, ибо она мне лично ничего не даёт, а у кого спрашивал те не могут обьяснить в чём преимущество. А спрашивал я у закоренелых ООПников-профессионалов. Все отнекиваются общими фразами, а готовых примеров привести не могут..
Я прекрасно знаю, что потребителю нужны простые и эффективные вещи, которые будут быстро и качественно работать, а что там под капотом их не волнует и это правильно.
Flat Отправлено: 4 декабря 2018 — 08:23 • Тема: Размышлизмы о движке • Форум: О жизни

Ответов: 64
Просмотров: 33345
Yamaliya пишет:
дали бы хоть взглянуть

Работа пока не окончена, то есть пока что-то выкладывать смысла нет. Полностью готовы функции по работе с файлами. Отличительной особенностью является то, что насколько это возможно данные буду писаться на старое место на диске физически, что разгружает сервер. Исключена возможность обнуления файлов при отключении например питания сервера.
Вот кому интересно:
Спойлер (Отобразить)

Пользовательские данные будут сохранятся в более приемлемом формате через разделители, а рабочие данные как массивы, чтобы можно было их сразу инклюдить в код.
Сейчас делаю регистрацию. Шаблоны у же готовы, осталось ещё сделать активацию по ключу и приём регистрационных данных.
-------------
ООП не будет и не ждите Подмигивание
Я вообще считаю, что добавление ООП в ПХП было серьёзной ошибкой. Язык то создавался простым и понятным. "ООП в вебе лучший способ полностью загрузить сервер ненужными действиями", как кто-то хорошо сказал.
В этом смысле разворот движка в сторону ООП было серьёзной ошибкой, которая сейчас аукнулась отсутствие разрабов-непрфессионалов. А профессионалы с эти движком связываться просто НЕ БУДУТ. Думаю, с этим никто спорить не будет.
Простота была потеряна, и пора очень пора её возвратить.
Команде надо было улучшить существующий код и всё. А сейчас придётся всё переделывать..


*********************************
большие куски кода прячьте, пожалуйста, в тэг "спойлер".
модератор.

Страниц (13): В начало « ... 2 3 4 5 [6] 7 8 9 10 ... » В конец

Яндекс.Метрика   

Powered by ExBB
ExBB FM 1.0 RC1 by TvoyWeb.ru
InvisionExBB Style converted by Markus®

[Script Execution time: 0.0461]     [ ]