ExBB Community » Разное » О жизни » Размышлизмы о движке

Страниц (5): « 1 2 3 [4] 5 »
 

46. 1Bot - 4 октября 2018 — 09:27 - перейти к сообщению
Flat
Вы многого хотите от просто форума.
47. Flat - 5 октября 2018 — 08:07 - перейти к сообщению
1Bot
Действительно многого. Может это и не нужно на определённом этапе, но будем иметь в виду на будущее..
48. Flat - 28 ноября 2018 — 10:55 - перейти к сообщению
Flat пишет:
Переделал всё обратно.

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

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

------------
49. Yamaliya - 30 ноября 2018 — 12:37 - перейти к сообщению
Flat , дали бы хоть взглянуть...
50. Flat - 4 декабря 2018 — 08:23 - перейти к сообщению
Yamaliya пишет:
дали бы хоть взглянуть

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

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


*********************************
большие куски кода прячьте, пожалуйста, в тэг "спойлер".
модератор.
51. Sigurni - 6 декабря 2018 — 10:41 - перейти к сообщению
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-аналогов, если мы говорим о файлах последовательного доступа (а у вас, судя по коду, они именно такие). И функционал, которые эти функции предоставляют, на порядок выше того, что у вас. В частности, можно сохранять ключи, многомерные массивы. А с вашими функциями, где фигурируют числовые ключи, работать будет крайне неудобно, вы сами это поймёте, когда перейдёте от ядра к функционалу.

Flat пишет:
Я вообще считаю, что добавление ООП в ПХП было серьёзной ошибкой.

Да что вы говорите! Вы считаете несколько легковесных дополнительных операций (да и то на C), как накладных расходов от ООП в PHP, серьёзной ошибкой, и при этом замахиваетесь на написание собственной СУБД на этом языке, которой предстоит обрабатывать объёмные файлы? Имхо, вместо того, чтобы быть велосипедистом, стоит просто подучить ООП (а не отрицать его) и работу с полноценными СУБД, в том числе NoSQL. А эти функции лучше забудьте и не тратьте на это время, это полная дичь.
52. Flat - 8 декабря 2018 — 10:08 - перейти к сообщению
Вышеприведённый код скопирован мной с пробного файла, а не с готового, по ошибке, поэтому содержит несколько явных ошибок. То есть я уже давно это переделал. Хотя принцип прежний остался.
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.

Я читал много книжек про ООП, даже такие, которые вы в глаза не видели и знаю как работают с ооп в пыхе. Могу наворотить такого что уши в трубочку свернутся и не только у меня.. Но я ПРИНЦИПИАЛЬНО не использую сию методику, которая на мой взгляд губит всю индустрию ПО на корню. И использовать не буду, ибо она мне лично ничего не даёт, а у кого спрашивал те не могут обьяснить в чём преимущество. А спрашивал я у закоренелых ООПников-профессионалов. Все отнекиваются общими фразами, а готовых примеров привести не могут..
Я прекрасно знаю, что потребителю нужны простые и эффективные вещи, которые будут быстро и качественно работать, а что там под капотом их не волнует и это правильно.
53. Yamaliya - 9 декабря 2018 — 10:47 - перейти к сообщению
что то навеяло Радость
Цитата:
Слишком много красивых и славных слов.
Не пора ли наконец заняться делом?!
54. Flat - 9 декабря 2018 — 14:26 - перейти к сообщению
Yamaliya пишет:
что то навеяло

Да, вы правы. Вместо этих излишних дискуссий я лучше бы накалякал столько же строк кода..
55. Flat - 9 декабря 2018 — 17:23 - перейти к сообщению
Flat пишет:
Такая система применяется многими с успехом и ещё не было нареканий, могу привести некоторые ссылки. например:

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

Также заменил функции file() на собственную реализацию. Оказывается она не использует разделяемую блокировку. Теперь всё ok
56. Flat - 11 декабря 2018 — 06:55 - перейти к сообщению
Почитал так недавно старый форум, на котором обсуждали старые версии движка(ещё не оопнутого). Там одна проблема была это обнуление файлов. Сейчас эта проблема исправлена. Я посмотрел код старой версии и нашёл этот баг. К сожалению те ребята не смогли это увидеть в своё время. А когда форум разделился, на данном усиленно начали доказывать, что те версии небезопасны. Дык и данная версия небезопасна ибо много уже исправленных проблем просто не вошло в дистрибутив. Однако та версия была гораздо проще, код яснее, почему бы ещё тгда не исправить несколько ошибок? По всей видимости кое-кто решил срубить бабок на этом деле.. Ну, ну..
57. 1Bot - 11 декабря 2018 — 10:43 - перейти к сообщению
Flat , то дела давно минувших дней.
Вот от того момента много времени прошло, но существенно так и не продвинулось дело.

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

Скорость развития желаний всегда больше скорости разработки.
Это не укор Вам, такова реальность. Подмигивание
58. Flat - 11 декабря 2018 — 12:11 - перейти к сообщению
1Bot пишет:
У Вас тоже кода с прямым доступом к файлам до сих пор нет.

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

Смотря в какую сторону..
В данном движке пошли на усложнение, хотя надо было не переписывать всё, а брать тот старый и просто напросто вылизать код, устранив некоторые баги, и добавив функционала. А теперь куда ушли? Мне лично не нравится в какую сторону уехал код с появлением 2 версии..
59. Sigurni - 11 декабря 2018 — 18:14 - перейти к сообщению
Flat пишет:
Также заменил функции file() на собственную реализацию. Оказывается она не использует разделяемую блокировку. Теперь всё ok

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

Flat пишет:
Дык и данная версия небезопасна ибо много уже исправленных проблем просто не вошло в дистрибутив. Однако та версия была гораздо проще, код яснее, почему бы ещё тгда не исправить несколько ошибок? По всей видимости кое-кто решил срубить бабок на этом деле.. Ну, ну..

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

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

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

Flat пишет:
У меня были варианты такого кода. много экспериментировал. Но всё это настолько сложно, что легче, гораздо легче просто использовать sqlite.

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

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

...но надо в одиночку сесть и пытаться переизобрести то, над чем уже поработали сотни людей до этого. Какая ниша сейчас есть у файлового форума? Те 4 человека, что остались здесь?
60. Flat - 12 декабря 2018 — 07:56 - перейти к сообщению
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, очём много писано. Даже в вобле форумы глючат не по детски. И зачем мне это нужно?
Я сейчас беру последнюю безоопную версию, и начинаю править код под то представление о нём, которое есть у меня. Старая ветка будет продолжена!
Ждите новую версию движка!

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

Powered by ExBB
[Script Execution time: 0.0354]     [ ]