Flat
Вы многого хотите от просто форума.

1Bot
Действительно многого. Может это и не нужно на определённом этапе, но будем иметь в виду на будущее..

В который раз всё переделал. Раньше менюшки у меня прописывались в своём конфиг-файле, поэтому можно было менять конфигурацию меню прямо в этом файле. Теперь я от этого отказался по нескольким причинам.
1. Зачем постоянно греть конфиг, да и сервер, если конфигурирование меню происходит отнюдь не часто? Даже можно сказать - никогда..
2. Ради убыстрения и упрощения кода.
вот пример такого шаблона:

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

------------

Flat , дали бы хоть взглянуть...

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

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


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

Да ну? Я могу вам сходу привести как минимум 2 примера, когда у вас произойдёт повреждение файла при одновременном доступе, и даже без "отключения питания сервера" (очень повеселила эта фраза).

1. Пользователь A читает массив (вызывается функция sibb_getArr) и решает его обновить (вызовом sibb_saveArr). В этот момент (аккурат до вызова flock) приходит пользователь B и начинает читать массив, чтобы опять же его обновить. Т.к. изменения, внесённые пользователем A, находятся ещё только в ОЗУ, пользователь B получает старые данные (без учёта изменений пользователя A). В результате мы получаем состояние гонки процессов, и изменения того пользователя, процесс которого первым выполнит fwrite, будут безвозвратно утеряны.
2. Пользователь A открывает тему (вызывается функция sibb_getTab) и добавляет в неё сообщение (вызывается функция sibb_saveTab). В этот момент, пока процесс пользователя A работает с tmp-файлом, приходит Пользователь B, чтобы тоже добавить сообщение. Его процесс ничего не знает про то, что процессом пользователя A создан tmp-файл, уже с новым сообщением, и читает старый файл (не tmp), где этого сообщения нет. Тем временем процесс пользователя A закончил работу с tmp-файлом и вызывает rename. Тоже самое спустя некоторое время сделает процесс пользователя B. В результате, сообщение пользователя A будет утеряно.

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


Да что вы говорите! Вы считаете несколько легковесных дополнительных операций (да и то на C), как накладных расходов от ООП в PHP, серьёзной ошибкой, и при этом замахиваетесь на написание собственной СУБД на этом языке, которой предстоит обрабатывать объёмные файлы? Имхо, вместо того, чтобы быть велосипедистом, стоит просто подучить ООП (а не отрицать его) и работу с полноценными СУБД, в том числе NoSQL. А эти функции лучше забудьте и не тратьте на это время, это полная дичь.

Вышеприведённый код скопирован мной с пробного файла, а не с готового, по ошибке, поэтому содержит несколько явных ошибок. То есть я уже давно это переделал. Хотя принцип прежний остался.

Хорошо, повеселимся вместе..

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

Такого не может быть, ибо читает массив из файла он опять же после вызова функции flock и никак иначе. А в внутри этой функции если что ожидает своей очереди.
И о какой такой "гонке процессов" вы говорите: действительно не пойму. Просветите пожалуйста.
Теперь по второму пункту.

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

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

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

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

Я всё понимаю даже лучше вас, так как уже десятки вариантов перепробовал и говорю по опыту а не из головы. Я не теоретик, а практик. Числовые ключи при наличии документации не проблема. У меня на каждый такой файл есть документ, где прописаны что каждый ключ обозначает. Также это позволяет убыстрить код. Кому нужно тот всё поймёт. А постоянно держать строковые ключи ради того, что когда-то кто-то там не сможет разобраться это просто засорять код.

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

В данном движке, который я делаю, субд не будет. Однако эксперименты, которые я делал говорят о том, что эффективность такой реализации была бы не ниже mysql.

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

что то навеяло

Да, вы правы. Вместо этих излишних дискуссий я лучше бы накалякал столько же строк кода..

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

Также заменил функции file() на собственную реализацию. Оказывается она не использует разделяемую блокировку. Теперь всё ok

Почитал так недавно старый форум, на котором обсуждали старые версии движка(ещё не оопнутого). Там одна проблема была это обнуление файлов. Сейчас эта проблема исправлена. Я посмотрел код старой версии и нашёл этот баг. К сожалению те ребята не смогли это увидеть в своё время. А когда форум разделился, на данном усиленно начали доказывать, что те версии небезопасны. Дык и данная версия небезопасна ибо много уже исправленных проблем просто не вошло в дистрибутив. Однако та версия была гораздо проще, код яснее, почему бы ещё тгда не исправить несколько ошибок? По всей видимости кое-кто решил срубить бабок на этом деле.. Ну, ну..

Flat , то дела давно минувших дней.
Вот от того момента много времени прошло, но существенно так и не продвинулось дело.

У Вас тоже кода с прямым доступом к файлам до сих пор нет.

Скорость развития желаний всегда больше скорости разработки.
Это не укор Вам, такова реальность.

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

Смотря в какую сторону..
В данном движке пошли на усложнение, хотя надо было не переписывать всё, а брать тот старый и просто напросто вылизать код, устранив некоторые баги, и добавив функционала. А теперь куда ушли? Мне лично не нравится в какую сторону уехал код с появлением 2 версии..

Вы решили ровно половину задачи. При работе с записью нужно использовать не разделяемую, а исключительную блокировку. И да, даже когда читаете из файла. Иначе описанные мной в предыдущем сообщении случаи всё равно будут случаться в ваших изобретаемых велосипедах функциях, и будете получать обнуление. Ещё раз внимательно смотрите includes/fm.class.php, методы FM::_Read2Write() и FM::_Write(). За вас всё уже придумано.


Аргументируйте, что тут небезопасно. За 10 лет работы нового ядра (ООПнутого, как вы выражаетесь) не было ни одного обнуления и серьёзного взлома. На старых версиях такое происходило регулярно. Код был яснее? Да ну, в чём принципиальное отличие, кроме того, что были изменены файловые функции и местами переименованы другие файлы/функции? Вы говорите ООП? Так там нет по сути никакого ООП. Всего несколько системных классов, которые на самом деле работают как пекеджи/неймспейсы для функций, а не полноценные объектные сущности. Про "бабки" вообще смешно читать. Вам надо не функции, а комедийные детективы писать.


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


Вот была же хорошая мысль, но...


...но надо в одиночку сесть и пытаться переизобрести то, над чем уже поработали сотни людей до этого. Какая ниша сейчас есть у файлового форума? Те 4 человека, что остались здесь?

Не нужно. Доки почитайте.

Отсюда

Почитайте ветку где обсуждались проблемы и их лечение и сравните с кодом в дистрибутиве.

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

Это уж не вам решать.

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

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

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