Форумы / National / Russian / Тех. поддержка / Пояснения по проекту

123>>>

Antar
#1 08.08.2008 20:59
У меня (может и еще у кого) есть непонимание сути данного проекта (котонти).
Поэтому я задам вопросы, надеюсь, будут ответы.

1. Какова цель проекта?
2. Планируется ли постоянное compatibility (забыл, как по-русски) с плагинами и скинами седитио?
3. Стоит ли действительно уходить совсем от Седитио? Ведь можно хакнуть несколько основных файлов, а все остальное делать только плагинами. Причина - если проект загнется - возможность возврата на седитио.
4. Как авторы проекта видят его продвижение в массы? Ведь на данном этапе сайт закрыт, новых пользователей не намечается, а большинство тех кто тут, смотрят с интересом со стороны ( но рук не марают :) ).
5. Зачем менять префиксы в бд?, не повлияет ли это на пункт 2?
6. Кто хозяин домена?
7. Кто хозяин будущего движка?
8. Зачем установлен трак. Не лучше ли было доделывать тракер седитио? Как-никак - одним хорошим плагином больше (хотя, как я вижу - трак намного мощней?)

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

Если у кого-то еще есть вопросы, добавляйте.
Trustmaster
#2 09.08.2008 05:26
1. В коротком периоде - устранение ошибок, внедрение имеющихся разработок, реализация запрошенных фич. В долгосрочном периоде - новое ядро и репозеторий плагинов, способные конкурировать с другими популярными CMS по удобству и функциональности, сохраняя при этом привычную стабильность, простоту и безопасность.

2. Полная обратная совместимость - удовольствие дорогое. Поэтому мы планируем постепенное внедрение нововведений, если такие имеются. По крайней мере, в ветке 0.0.x никаких изменений в плагинах и скинах не потребуется. А к ветке 0.1.x будет видно, живёт проект, или заглохла инициатива.

3. Одной из причин для создания нового проекта была недостаточная модульность, которая вынуждает использовать хаки ядра вместо плагинов. Поэтому мы планируем вывести весь функционал, не относящийся к базовой системе, в плагины, попутно добавляя необходимые хуки там, где нужно. Это нанесёт некоторый ущерб производительности, но значительно упростит процесс разработки как ядра, так и плагинов.

4. На данном этапе у нас нет другого выбора. В лицензии есть только маленькая лазейка, которую мы пытаемся использовать. И так как Оливье с вероятностью 90%, мягко говоря, эта затея не понравится, он может быстро прикрыть эту лавочку. И до тех пор, пока в репозитории находится код с копирайтами Neocrome, мы не можем открыть его для масс. Если мы дойдём-таки до версии 1.0.0, где спорного кода не будет, то сможем открыть репозиторий и сайт для внешнего мира, явив ему новую CMS, основанную на многолетнем опыте LDU и Seditio.

5. Префиксы в бд никто менять не будет. Если вас смущает папочка branches/cotonti в репозитории, не обращайте на нее внимания - это давняя попытка Kilandor'а сваять новую CMS с нуля. Что касается именно префиксов, то формально, их можно менять даже в стандартном Seditio.

6. Jason Booth (Kilandor).

7. Народ :) Новый код лицензируется под BSD, авторские права на отдельные части сохраняются за их оригинальными авторами, авторские права на весь код проекта в целом закрепляются за составной единицей "Cotonti Team", которую (если возникнет-таки необходимость) нужно будет зарегистрировать.

8. KIlandor поставил Трак, и настаивает на том, что это скорее необходимость, чем каприз ввиду поддержки SVN, дорожной карты и т.д. и т.п. Над трекером надо работать, об этом все говорят, но никто не делает. У меня на него нет времени, Kilandor пишет плагины для интеграции Trac в Сед, остальные курят в сторонке и выдвигают предложения / предлагают выдвижения.

Есть ещё вопросы, пишите, отвечу.
May the Source be with you!
Asmo
#3 09.08.2008 12:15
Касательно 3 пункта
Одной из причин для создания нового проекта была недостаточная модульность, которая вынуждает использовать хаки ядра вместо плагинов. Поэтому мы планируем вывести весь функционал, не относящийся к базовой системе, в плагины, попутно добавляя необходимые хуки там, где нужно. Это нанесёт некоторый ущерб производительности, но значительно упростит процесс разработки как ядра, так и плагинов.

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

Имхо лагины нужны как незанчительные расширения, вроде пассворд рековери, различные блоки и прочие рюшки.
А такие вещи как например блоги пользователей, доска объявлений с множеством категорий, какойнибудь мегакаталог лучше делать как новый элемент ядра.
Тот же форум ни у кого не прийдет и в голову сделать его плагином :)

Оливер предусмотрел такую возможность, но не до конца немного. Есть всего пару моментов буквально, где необходимо трогать код ядра.
Вернее даже один пока вижу: в function sed_loadconfigmap() добавить умолчальные конфиги для нового модуля, без этого, их уже добавленные в БД, не возможно изменять, ну и в плане языковых переменных, можно в общие языковые файлы добавлять новые константы, ну или уж если совсем не хочется никуда лезть, то отдельный языковый файл заинклудить для конкретного модуля тоже не тяжело.

Чуть позже я выложу пример нового элемента ядра и кое какое руководство по внедрению. сейчас я проверяю все ньюансы.

Модульность в СЕ достаточная как оказалось, в движок можно добавить новый элемент ядра и совершено безболезненно его удалить, в новых элементах ядра сохраняется практически все возможности по администрированию, как и для уже сущесвтвующих элементов ядра.

Такой подход ничем не хуже плагинов, а даже лучше, все что нужно - это забросить папку в core и выполнить sql с правами, конфигами и новыми таблицами.
Sergeich
#4 09.08.2008 18:17
по поводу модулей поддерживаю Асмо, сделать разделение на модули и плагины это идеологически правильно (большому прибамбасу модуль, мелкой рюшке - плагин), значительно проще, чем вынести всё в плагины и вообще айс :). Сам думал, почему же никто не пишет новые модули для ядра сед, а всё пытаются впихнуть в плагины или же хакают безбожно ядро.
Кстати, помнится в ЛДУ можно было создавать копии файлов ядра, вносить в них изменения и каким то образом заставлять их работать совместно с основным ядром, скорее всего эта фича сохранилась и в Сед.
Trustmaster
#5 10.08.2008 11:55
Да, я в принципе предлагаю ввести два отдельных понятия - модуль и плагин. Пример модуля - форум. Пример плагина - карма. Идея модуляризации в том, что для добавления некоторой новой возможности на сайте не должно быть малейшей необходимости трогать ядро. Т.е. это должна быть установка либо нового модуля, либо нового плагина (т.е. плагины расширяют функционал модулей).

Да, хуки и инклюды - вселенское зло, когда дело касается производительности движка. В порядке эксперимента на одном из сайтов я их вообще вытравил как вид. Но необходимость в модульности против патчей возникла из практического опыта: когда необходимо поддерживать несколько сотен сайтов, а не один-два, то наложение очередного хака превращается в сущий ад, учитывая то, что на разных сайтах требуется разный набор хаков, которые, кроме прочего, ещё и зависят друг от друга.
May the Source be with you!
Asmo
#6 11.08.2008 02:23
Да собственно вот уже готовое решение есть для этого /admin.php?m=other оно в русской локализации даже значится как "модули".
Чтобы модуль появился там, достаточно выполнить набор sql запросов:
1) добавить новый элемент в sed_core, появляется новый модуль

2) добавить набор прав в sed_auth , у нового элемнта появляется кнопка редактирования прав

3) добавить настройки по необходимости в sed_config , появляется соответствующая кнопка со ссылкой на редактирование конфига

Админ-часть нового модуля кладется в system/core/admin/admin.newmodule.inc.php
Да, еще, иконка модуля берется автоматически из папки system/img/admin ? туда нужно ,eltn добавить гифку newmodule.gif например :)
Управление для нового модуля готово.
Frontend часть модуля исполняется по всем правилам жанра движка c разброской файлов по соответсвующим папкам.

Занимался этим все выходные, необходимость вмешиваться в ядро не обнаружена, кроме того случая что я уже описал в первом посте. Сакральный смысл этого массива с умолчальными настройками в sed_loadconfigmap() для меня так и остался загадкой , может он делался из расчета быстрого восстановления работоспособности после потери базы данных, но смысл поднятия пустого движка без потерянных данных, мне не ясен.
Отредактировано: Asmo (11.08.2008 02:30, 15 лет назад)
Asmo
#7 11.08.2008 02:28
Еще один момент, почему я собственно нажимаю на модули, а не делаю плагинами.
Для поисковков plug.php?e=n это все один и тот же файл с разными параметрами, соответсвенно и отношение к нему такое же, плюс ко всему еще длиннее борода из параметров чем в модуле получается.
Trustmaster
#8 11.08.2008 07:25
Спасибо за информацию, попробуем развить эту идею. Что касается сео-приглядности плагинов, Ломби сейчас вовсю тестирует изменение формата ссылок "на лету" с помощью шаблонов ссылок. Нечто подобное, но более универсальное, мы впоследствии реализуем для всех.
May the Source be with you!
Dayver
#9 11.08.2008 12:14
Выскажу свое мнение:
Идея про популяризацию модулеписательства вместо исключительно плагинописательства мне оч понравилась. Но то что до сих пор написание какого либо модуля это ну очень редкий случай частично напрямую связано с сложностью процесса установки модуля(который описал Asmo). Поскольку не многие могут написать плагин (про модуль и говорить нечего), а значит и не каждый сможет справиться с задачей установки модуля......мы же говорим про будущую популяризацию котонти, а если так то нужно учитывать факт что чайники тоже будут ставить модули (в зависимости от их нужд) значит, и процесс установки модуля должен быть не сложнее установки плуга.
Pavlo Tkachenko aka Dayver
Amro
#10 16.08.2008 20:09
Идея про популяризацию модулеписательства вместо исключительно плагинописательства мне оч понравилась. Но то что до сих пор написание какого либо модуля это ну очень редкий случай частично напрямую связано с сложностью процесса установки модуля(который описал Asmo). Поскольку не многие могут написать плагин (про модуль и говорить нечего), а значит и не каждый сможет справиться с задачей установки модуля......мы же говорим про будущую популяризацию котонти, а если так то нужно учитывать факт что чайники тоже будут ставить модули (в зависимости от их нужд) значит, и процесс установки модуля должен быть не сложнее установки плуга.

Думаю те кто справляется с установкой плагинов, те справяться и с установкой модуля, стоит лишь продумать удобный инсталлятор для них, так же как и у плагинов. Возможно для этого придётся немного изменить концепцию модулей, но не более.
Dayver
#11 16.08.2008 20:31
Полностью поддерживаю такую трактовку вопроса.
Pavlo Tkachenko aka Dayver
Ratibor
#12 20.08.2008 17:56
Не стал создвать новую тему, спрошу здесь.
По какому принципу накидали плагинов ?
Лишь бы были ?
Некоторые дублируют друг друга, некоторые впринципе нерабочие,
некоторые не доделанные и т.п.
Чтоб не быть голословным, плагин ajax_poll впринципе не рабочий,
после голосования тебя выкидывает с сайта.
Так же что там делают news, textboxer2, recentitems ?
Они же есть в основной ветке.
Если они чем то отличаются от тех что в основной ветке, то почему бы тогда не выбрать лучшие и не включить в основную ветку ?

Так же на данном этапе не вижу смысла в добавлении jQuery,
в данный момент получается как в поговорке: мы посовещались и я решил.
jQuery в голом виде абсолютно не нужна, нужны плагины и нужен аякс.
На данный момент плагинов с поддержкой других JS FW и Ajax больше.
C jQuery я знаю только один плагин - это FAQ от Tefra, да и тот глючный.
Так же есть thumbnailviewer для jQuery, но он убогий, тот же lytebox намного лучше.
Либо надо все это включть в комплексе, либо вообще не включать.
А то на данный момент ситуация как с плагинами - лишь бы было, авось кто-то доработает напильником.

Также я думаю уместно будет выкинуть два скина из основной ветки, есть же отдельная ветка для скинов.
И если кто будет добавлять плагины, чтоб обязательно их подгоняли под дефолтный скин.
А кто выкладывает скины, подгоняли их под плагины.
Причем все это должно обновлятся постоянно, а не так что залил скин, а потом забил на него.
Ну и если кто решится выкладывать скин, то пусть выкладывают полноценный скин.
Вот что меня больше всего бесит в скинописателях, так это то что сделают главную страничку и выкладывают, типа пользуйся рванина, а на все остальное наплевать. В последнее время на neocrome.net, да и других сайтах по Seditio, такого мусора накидали кучу.
В общем все должно работать как говорится из коробки, а не так как сейчас - доработай напильником.

Ну и для кучи по поводу сайта:
ИМХО было бы уместно добавить русский (ну и другие по желанию) язык :)
Есть же нормальный перевод от Antar, правда он в win1251, но я в траке выкладываел переделанный в utf-8, правда это предыдущий его перевод, но если Antar не против, то я могу переделать его последний перевод в utf-8 и выложить.
Хотя лучше чтоб это сделал он сам.
И какую цель преследует внизу полоска "Home / About Us / Documentation / Legal / FAQs / Contact" ?
Она все равно никуда не ведет.
Как говорится если на сцене висит ружье, то оно обязательно должно выстрелить.
А если оно не будет стрелять, то нехрен его туда вешать.

P.S. Ну и думаю по русскому языку (да и другим non latin) нужно договорится, в какой кодировке делать.
А то все делают по старинке в win 1251. ИМХО давно надо перейти на utf-8.
С переходом на utf-8 решится много проблемм.
К примеру таже ява работает только с utf-8.

P.P.S Ну и совсем не понятно за каким в Revision 31 было добавлено "added SQL scheme and several API functions for the new bbcode parser implementation" ?
ТО идут разговоры чтоб вообще выкосить bbcode из ядра, что было бы уместней, то в ядро интегрируется еще больше этих самых bbcode. Если что и интегрировать, то это xbb, на сегодня он ИМХО превосходит все поделки для Seditio.
Понятно что хотелось бы своего, но вот когда будет это свое как минимум не уступающим xbb, вот тогда и можно его включать.
А вообще для начала надо определится со всеми необходимыми bbcode, а потом чтото воротить. Тот же hide, попросту необходим, но его нет в основных, а только отдельным плагином, а это в некоторых случаях доставляет сильные неудобства.
В крайнем случае сделать API чтоб можно было подключать разные парсеры и редакторы, а не толкать bbcode в MySQL базу, на сайтах-визитках может быть это то что доктор прописал, но на загруженных сайтах это зло, причем самое злейшее.
Ну уж если совсем-совсем приспичило создавать "several API functions for the new bbcode parser implementation", то хотябы хранить их (bbcode) не в базе а в отдельном файле.

P.P.P.S И вопрос к Trustmaster:
по поводу твоего плагина attach.
На сколько он с точки зрения безопасности, хотябы по сравнению с тем же pfs ?
И если он нормальный, то может стоит выкосить этот pfs и заменить его твоим плагином, а лучше интегрировать его ?

Ну и на последок мое ИМХО по поводу плагинов как таковых.
lang файлы конечно хорошо, но .. пусть попробует новичек разобраться хотябы в том же recentitems.
Плагины, как и ядро, не должны содержать html код.
Если плагин предусматривает вывод html кода, то его уместней выносить в tpl файл.
На крайняк, должно быть так, чтоб пользователь мог легко изменить html код внутри плагина.
Некоторые плагины, так и сделаны, но таковых еденицы, в основном html тупо встроен в php, и попробуй там разберись если тебе приспичит изменить html код выводимый этим плагином. А таких операторов как table, tr, td вообще впринципе не должно быть внутри ядра или плагина, только в tpl. Ну и как я уже написал выше, не нужно сувать что не попадя в SQL базу, только при острой необходимости.
Ну и господа админы, давайте в первую очередь думать о пользователях, а потом уж об удобстве администрирования.
Разговаривал со многими админами и большинство из них говорит "а мне так нравится" и им наплевать удобно это пользователям или нет. К примеру как в прошлом релизе Seditio все ждали подфорумы, а Оливер вместо подфорумов забабахал корзину. Алес.
Не задавай глупых вопросов, не услышишь вранья.
Отредактировано: Ratibor (20.08.2008 20:40, 15 лет назад)
Trustmaster
#13 20.08.2008 20:39
1. Плагины накиданы по принципу создания единой базы плагинов. Причем не для "скачал-поставил", а в первую очередь для дальнейшей доработки. Например, news и textboxer2 там нестандартные. Каюсь и посыпаю голову пеплом, что не проверил их работоспособность на всех версиях движка, не исправил все ошибки и не написал по инструкуции на двух языках сразу. Но тот, кто это сделает, пусть первым кинет в меня камень :wink

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

3. Стандартные скины - на общее обсуждение в международный форум.

4. Antar работает над новой версией локализации, когда закончит, тогда она (в utf8) и будет включена в основную ветвь. Что касается этого сайта, то очень хочется скооперировать сообщество из разных стран, вместо того чтобы все расползались по своим углам, а раз так, то надписи на английском не должны вызывать проблем. Полоска внизу преследует ту же цель, с которой Xiode ее туда добавил изначально.

5. Да собственно, все предложения пока за переход на UTF-8, работа над этим ведется. Следующий шаг - рефакторинг на mbstring и новая локализация в utf8.

6. По поводу bbcode советую повнимательнее прочитать ветку в Core Labs. Xbb, к сожалению, мы интегрировать не будем хотя бы из-за его лицензии. Никакие новые ббкоды никуда не добавляются. Добавляется универсальный API, который позволит не только управлять ббкодами в админке, но и в пользовательских плагинах. Привязки ббкодов к конкретному редактору больше не будет, и в комплекте с разными редакторами можно будет устанавливать специфические ббкоды. В качестве нового дефолтного редактора попробуем прикрутить markItUp! с подробными инструкциями, как создавать другие плагины-редакторы. Технически новый парсер реализован на все тех же строках и регулярных выражениях (я бы, может, и рад воспользоваться каким-нибудь бинарным модулем из PECL или написать парсер на Си, да вот только тогда всем надо будет как минимум на VPS переезжать). Можно, конечно, "подсмотреть" идею конечных автоматов у xBB или еще что изобресть, но пока это не самоцель. Про производительность MySQL беспокоиться не стоит, ибо кэширование для этого есть. Кроме того, реализуется новая опция "рендеринга по требованию" для страниц и форумов, т.е. парсинг происходит после того, как были произведены изменения в тексте, а не при каждом отображении. От идеи модульных парсеров в пользу одного универсального пришлось как раз отказаться из-за потерь в производительности, которые возникают вследствие этой самой модульности.

7. В attach я старался закрыть все известные дыры, связанные с закачкой файлов в php, кроме тех, которые в принципе не закрываются (дыры IE в частности). Я, конечно, постарался предоставить API для того, чтобы вложения можно было реализовать в любом плагине или модуле ядра, но PFS - это все-таки немного другое. Иногда нужно именно "личное файловое пространство", а не возможность прикреплять файлы к сообщениям. Так что просто взять и выкинуть PFS на свалку истории - опрометчивый поступок. Доработать - более взвешенный. Все это вопрос чьих-то человеко-часов.

8. Про разделение кода и html полностью согласен, да и все согласны.
May the Source be with you!
Ratibor
#14 20.08.2008 21:10
1. Может мы е поняли друг друга.
Я не всмысле того что не надо добавлять плагины, к тому же сейчас там накиданы плагины которые и так у всех есть.
Лучше пусть каждый добавит по одному плагину, но полностью рабочими.
На крайняк создать ветку в которой обсуждать и координировать все это.
2. Понятно для чего добавлен jQuery, но опять же но..... а гидэ тогда как минимум аякс ?
3. :)
Судя по последней ветке, которую ты перевел и перекинул, международное сообщество мало интересуется, оно занято более глобальными проблеммами, там общаются одни русские на английском, попахивает маразмом :)
4. По поводу международной кооперации я конечно согласен, но это в идеале.
А в реальности если по английски все могут прочитать и понять о чем речь,
то вот с писаниной намного сложней. Небольшие предложения также все могут написать.
А вот ясно выразить мысль, тем более на пол километра, вот здесь сложнее, таких еденицы :)
ИМХО продуктивней для всех, будет изложение мыслей вести на родных языках.
А гуру уж потом суммируют все. Удобней и продуктивней получится.

6. А что не так с лицензией xBB ?
Скрипт распространяется бесплатно по лицензии GNU GPL v 2. Согласно этой лицензии вы можете свободно использовать, распространять и менять этот скрипт при условии, что ваши собственные программные продукты, использующие этот скрипт, не будут распространяться, либо будут распространяться по той-же лицензии GNU GPL.
В данный момент Seditio-n-0.0.1 не распространяется, что соответствует лицензии.
Или в будующем (после открытия кода на всеобщее обозрение) данный проект станет платным ?
То тогда получается, как правильно сказал Antony:
Получается что сообществу, за кучей красивых слов из первого и следующих сообщений, предлагается решать чьи-то "локальные бизнес задачи", при этом абсолютно не ясна мотивация разработчиков, которые должны будут воплощать всякие новые "бизнес-идеи" и "бизнес-потребности"
Сейчас проект не распространяется, а если после открытия он будет бесплатным, то я не вижу никакого нарушения лицензии xBB.
В общем если перевести на более понятный язык лицензию xBB, то получается.
Если хотите использовать xBB (оригинальный или измененный) в своих продуктах, то продукты должны быть бесплатными. А если вы решите рубить бабки в открытую, то плиз делитесь. А иначе боже упаси если они (ваши продукты) попадутся мне на глаза.

Тот же XTemplate сейчас юзается и ничего.
XTemplate is dual licensed using BSD and LGPL

LGPL в отличие от лицензии GNU GPL разрешает статическое связывание LGPL-программы с коммерческой.

Так что нарушение лицензии xBB будет в единственном случае - если продукт будет распространятся платно.

И раз ты говоришь что лицензия не подходит, то вывод напрашивается один. Или может я чегото не допонял ?
Не задавай глупых вопросов, не услышишь вранья.
Отредактировано: Ratibor (20.08.2008 22:19, 15 лет назад)
Sergeich
#15 20.08.2008 22:51
Я так понял этот проект хочет соханить ту же лицензию что сейчас имеет Сед, единственное отличие - решать всё будет не 1 человек "группа активистов" :). Всё это предлагалось и подробно разжёвывалось на неокром.нет, но Оливер проигнорировал предложение.

123>>>