Персональные планы на Drupal 8

Аватар пользователя andypost@drupal.org

В настоящий момент происходит опрос drupal.org сообщества на предмет участия в развитии внутренних частей drupal 8.

Желающие могут описать возможность личного участия в разработке Drupal 8

Большая просьба писать исключительно то, в чем Вам лично есть желание принять участие!

EDIT

Я предлагаю согласовать идеи и перспективы разработки, лично я хочу проработать UX для poll, blog, forum и рефакторинг системы кеширования. Если в issue будет достаточно тестировщиков и участников - у неё больше шансов попасть в ядро.

06.01.2012
Иннициатива вебсервисов - обощенная картина http://groups.drupal.org/node/198538

Ключевые слова:
Тип материала:
Версия Drupal:
0 Thanks

К материалу прикреплен опрос на тему «Желаете ли принять участие в разработке Drupal 8?»:

  • Помогу кодом 14 голосов
  • Помогу с темизацией 6 голосов
  • Помогу с UX 7 голосов
  • Неосилю 41 голос
  • Нет 9 голосов
Log in or register to vote

Комментарии

Аватар пользователя Виктор Степаньков ака RxB

Шестёрку не мог.
Семёрку не успел.
Может в восьмёрке помогу индурусским кодом

Аватар пользователя andypost@drupal.org
andypost@drupal.org 6 лет назад

Интересная статистика выходит, вроде как есть желающие, но никто не может написать какие части ядра их интересуют...

Неужели нет сформировавшихся намеряний, чтобы их описать, но сие странно.

Аватар пользователя neochief
neochief 6 лет назад

Я думаю наша самая мощная сила — понимание проблем интернационализации, и в этом, если кто не знает для себя темы, и можно помочь. НО как обычно, для начала надо оформить проблемы, а потом уж и решать.

Лично я возможно постараюсь включить функционал аякс-комментов в ядро, но с тем как у меня времени последние полгода все меньше и меньше — даже и не знаю.

Аватар пользователя andypost@drupal.org
andypost@drupal.org 6 лет назад

интернационализация да и локализация имеют заметные грабли... думаю, что действительно стоит сосредоточить усилия на них в первую очередь, да и стестированием будет проще :)

Аватар пользователя seaji
seaji 6 лет назад

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

Аватар пользователя andypost@drupal.org
andypost@drupal.org 6 лет назад

речь скорее идёт об инвестировании своего времени в размере нескольких часов в неделю, не более...

Поэтому и поднят этот вопрос: можно взяться за определенную часть системы и 1-2 раза в неделю уделять этому время...

Аватар пользователя seaji
seaji 6 лет назад
@drupal.org">andypost@drupal.org написал:
речь скорее идёт об инвестировании своего времени в размере нескольких часов в неделю, не более...

Да, это хорошо, а если наблюдается дефицит времени порядка 4 часов в день?

Аватар пользователя orangeudav
orangeudav 6 лет назад

А архитектура 8-ки хотя бы в общиъ чертах нарисована? Где то там про какие-то бандлы говорили вместо нодов.. Мне концепция нодов в текущей реализации представляется весьма убогой, но ссать в одиночку против ветра - энтузиазма не хватит..

В догонку: в современных тенденциях думаю стоит смотреть на взаимодействие друпала с NoSQL базами.. Ну и соответственно, поддержку SQL оставить лишь для обратной совместимости..

Аватар пользователя bratello
bratello 6 лет назад

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

Аватар пользователя darkdim
darkdim 6 лет назад

я вообще в шоке 8о() Зачем плодить ветки? Ну уж такая плохая 7-ка, что уже 8-ю затевают, хотя у людей дофига и больше проектов на 6-ке, и на семерку еще не скоро перейдут...

Аватар пользователя xxandeadxx
xxandeadxx 6 лет назад
darkdim написал:
Ну уж такая плохая 7-ка

что в ней плохого?

Аватар пользователя Виктор Степаньков ака RxB
xxandeadxx написал:

что в ней плохого?

Она вешает сервер (с) Шаманер
ОНА ТЯЖЕЛЕЕ ШЕСТЁРКИ РАЗ В ПИЦОТ(с) Половина леммингов отсюда
ПОД НЕЁ НЕТ МОДУЛЕЙ!!!!!(с) Тимофей Кондуров
Я поставил модуль FCK, скачал редактор CKE - НЕ РАБОТАЕТ! ГЛЮЧНОЕ ПОДЕЛИЕ (с) Кто-то отсюда неизвестный

Аватар пользователя Mirocow
Mirocow 6 лет назад
orangeudav написал:
Мне концепция нодов в текущей реализации представляется весьма убогой, но ссать в одиночку против ветра - энтузиазма не хватит..

присоединяюсь

Аватар пользователя Crea
Crea 6 лет назад

Преждевременно это все ИМХО...Невозможно хорошо планировать дела на будущее, не переварив опыт ближайшего настоящего (7.х), а это еще всем предстоит делать ближайшие 2-3 года. Большинству хороших идей и задумок еще предстоит появиться. Большинство выводов еще рано делать..
Ну а избыток энергии можно потратить на обкатку уже запланированного в контрибе в 7.х (слава богу, что Друпал расширяемая система!) да и ядро править не большой грех, если руки из нужного места (мое мнение).

Аватар пользователя axel
axel 6 лет назад

Есть прикольная тема сделать поддержку Fast CGI в Drupal. Хотя термин "fast cgi" фигурирует применительно к PHP давно, полноценная реализация работы приложений в этом режиме стала возможна только с PHP5.3. См. http://javascript.ru/blog/travisbickle/true-fastcgi-dlya-php-migraciya-t... Для Drupal имеющего довольно тяжёлый bootstrap ускорение для многих задач должно быть заметным.

Аватар пользователя bratello
bratello 6 лет назад
axel написал:
Для Drupal имеющего довольно тяжёлый bootstrap ускорение для многих задач должно быть заметным.

Тогда уже не парить мозги с PHP & Apache, а переписать Дрю на Node.js (Drupal.js). Модульность от этого только выиграет, поддержка хуков (отличная идея на самом деле) на javascript реализуется очень красиво, ноды и темизация (тоже отличное архитектурное решение) аналогично. К примеру модуль в таком случае мог бы выглядеть так (псевдокод):

DrupalApp.modules.book = {
        hooks: {
                perm:function() {
                        ...
                },
                link:function(...){
                        ...
                },
                init:function() {
                        ...
                }
        },
        themes:{
                book_title_link:function(link) {
                        ...
                }
        },
        pages: {
                book_admin_overview:function(...) {
                }
        },
        model: {
                schema : {
                        ...
                },
                queries : {
                        add_new_book:function(...){
                        }
                }
        },     
        menu: {
                'book': {
                    path : 'admin/content/book',
                    title : 'Books',
                    description : "Manage your site's book outlines.",
                    page_callback : DrupalApp.modules.book.pages.book_admin_overview, //Это на самом деле ошибка потому что обьект еще не определен, написано для наглядности.
//Решается путем определения DrupalApp.modules.book = {}; DrupalApp.modules.book.hooks = {....}; DrupalApp.modules.book.pages = {...} по отдельности.
                    access_arguments : ['administer book outlines'],
                }
        },
};

И так далее. В итоге прекрасно сохраняются все интересные парадигмы, скорость вычисления хуков в рантайм значительно увеличивается (сокращается область поиска - проход по списку DrupalApp.modules.xxx.hooks, хуки не нужно определять с префиксами модуля, каждый одноименный хук будет находиться в области видимости своего модуля), сохраняется кастомизация темизирования, появляется наконец полноценный уровень данных (DrupalApp.modules.xxx.model), упрощается доступ к функциональности уровня ядра (функциональность эта может находиться в DrupalApp.kernel, которая может аналогично расширяться и кастомизироваться). В node.js кажется уже появились потоки, значит можно отказаться от форков, и на каждый запрос отстреливать отдельный thread, наверняка есть возможность построить пул потоков (thread suspend mode), пул соединений к DB, ресурсные запросы обслуживать ресурсными потоками которые будут брать файлы прямиком из каталога (nginx must die) - все эти чудеса прямо под рукой. Плюс приличная интеграция с Java - большинство системных вычислений можно использовать из JVM.

Аватар пользователя andypost@drupal.org
andypost@drupal.org 6 лет назад

Дык сие и есть одна из основных иннициатив http://groups.drupal.org/wscci

И её координатор очень активно двигается в этом направлении
http://www.garfieldtech.com/blog/web-services-initiative
http://www.garfieldtech.com/blog/london-cfp

PS: node.js уже используют с дрю http://dgo.to/nodejs и группа http://groups.drupal.org/taxonomy/term/22528
PPS: а вот переписывание всего говорит в первую очередь о слабом представлении что есть ядро дрю, количестве контриб модулей и сайтов которые нужно поддерживать...

Аватар пользователя bratello
bratello 6 лет назад
@drupal.org">andypost@drupal.org написал:
Дык сие и есть одна из основных иннициатив

Я читал эти нитки, насколько я понимаю народ все еще не верит что в скором времени opensource V8 окажется на большинстве серверов Linux, а потому предпочитает традиционный PHP/MySQL. Немного странно это слышать от людей которые работают с opensource продуктами, не дальновидно это, уверен что Google приложит максимум усилий для того чтобы впихнуть V8 как минимум в шел. Недавно провел performance tests на числе Фибоначи, на V8 производительность уступает лишь Java JIT с разницей чуть меньше x2, но он оказалася в 50 раз быстрее файрфоксовского Rhino, и в 5 раз быстрее того же Rhino но со скриптом откомпелированым в Java байткод. Для меня это было настоящим сюрпризом, я всю жизнь проработал на нейтив типизированых языках, и мне казалось что динамические нетипизированые языки это кошмар с точки зрения непредсказуемости исполнения кода из-за отсутствия проверок типов на этапе компиляции, as well as проблем связанных с низкой производительностью. Первая догма была разрушена после ознакомления с Drupal, вторая догма рушится под напором Google.

А интеграция с Node.js это на самом деле лишь затычка.

@drupal.org">andypost@drupal.org написал:
переписывание всего говорит в первую очередь о слабом представлении что есть ядро дрю, количестве контриб модулей и сайтов которые нужно поддерживать...

Я прекрасно это понимаю, скорее даже основная ценность в модулях, а не в ядре. Но в 7-ке провели не мало изменений (DB layer полностю сменился), и никто от этого не умер. И судя по обсуждениям, переписывать никто ничего не боится, вопрос лишь в распространенности V8 на системах. Поддержку никто не отменяет, что с того что следующая версия сменит полностью среду исполнения. Но я уверен что Google сделает в этом направлении свое дело быстрее чем кто либо может представить, на сегодняшний день эта компания является основным двигателем opensource, с ее то возможностями. В конце концов, сегодня все больше интернет проектов предпочитают переезжать на Cloud Server, у меня на Rackspace есть небольшой сервер (512m Debian) на облаке, дешево и производительно. Кроме того, Drupal себя позиционирует как платформа для управления социальным контентом, домашние страницы публика по прежнему предпочитает делать на Wordpress. Нужно четко понимать какие цели ставит перед собой продукт, и какими средствами можно этих целей достичь.

Аватар пользователя orangeudav
orangeudav 6 лет назад

Позволю цитату с http://node-js.prcn.co.cc/

Цитата:

О проекте node.js

Учите английский, блядь! Это серверный однопоточный джаваскрипт-движок на событиях (libev), состоящий из гугловского якобы высокопроизводительного JIT-компилятора V8 и библиотеки асинхронного ввода-вывода к нему. В библиотеке присутствует HTTP-сервер, что позволяет получить что-то в духе эрланговского MochiWeb и питоновского TornadoWeb, но позволяющее писать клиентский (браузерный/AJAX) и серверный ('cкрипты') код на одном языке. Ну и конечно геморрой в стиле mod_perl + POE вам обеспечен. Тем не менее, говорят, это прогрессивно и круто. (Шутка)

Для особо одарённых, уточняю. Вышеперечисленное включает: вонючую, но встроенную вариацию memcached; невозможность без плясок с бубном, не снившихся питоновцам, задействовать более одного ядра; новые уязвимости из-за паразитной передачи данных в параллельно исполняющийся запрос; падучесть всей VM вместе с вашими фронт-эндом и бэк-эндом в стиле легендарной DOS при зацикливании или непойманном исключении в любом из обработчиков событий; возможность неправильно реализовать HTTP; феерический пул потоков для исполнения в нём unlink(); развесистые монады при вводе-выводе, не снившиеся хаскеллистам; ну и, конечно же, необходимость писать юнит-тесты на каждый чих, потому что только джедаи в состоянии безошибочно разыменовать хеш массивов хешей хешей массивов, а а компилятор попытки присвоить ёжику зайчика не ловит.

Но и это ещё не всё! Для затягивания сроков и удорожания разработки система включает: иллюзию эрланговской изоляции посредством порождения дочерних песочниц в рамках одного потока; циклы перебора байтиков в буфере в стиле Паскаля с неявным алиасингом; отсутствие возможности читать файлы построчно.

Аватар пользователя bratello
bratello 6 лет назад
orangeudav написал:
Позволю цитату

По-моему человек перепутал интернет с туалетом. Не хотелось бы сползать в холивар, но хотя бы несколько коментариев.

Якобы высокая производительность подтверждена тестами персонально, сравнивал Rhino, V8 & Java Native, на вычислении числа Фибоначи. Java Native бежит почти в два раза быстрее того же алгоритма на JavaScript V8.

HTTP server в Node.js пишется так:

var http = require('http');
 
http.createServer(function (request, response) {
    response.writeHead(200, {'Content-Type': 'text/plain'});
    response.end('Hello World\n');
}).listen(8000);
 
console.log('Server running at http://127.0.0.1:8000/');

По-поводу потоков, в V8 судя по публикациям они с недавна уже существуют, в Rhino для этих целей уже давно существует spawn. Я Rhino не плохо знаю, потому говорю о том что знаю (Кстати, Гугль уже давно использует Rhino на своих серверах для нужд Google Docs). Надежность движка в целом подтверждена опытом эксплуатации Chrome. Мой знакомый делал на Node.js высокоскоростной chat для онлайн обслуживания, очень доволен.

Аватар пользователя bratello
bratello 6 лет назад

Кстати, установка хуков в Drupal Style на любые методы в случае JavaScript могла бы быть значительно проще и производительнее:

var DrupalAPP = {kernel:{}, modules:{}};
DrupalAPP.kernel.install_hook = function(source, target, hookName) {
        var hooked = target[hookName];
        target[hookName] = function() {
                var args = [].slice.call(arguments);//получить аргументы функции
                args.push(target);
                args.push(hooked);
                source[hookName].apply(source, args);
        }
}

//Base module
DrupalAPP.modules.myModule = {
        model : {
                queries: {
                        add_some_data:function(params, callback) {
                                //ассинхронный вызов SQL
                                db.query(..., callback);
                        }
                }
        }
};

//Extension module with hook for DrupalAPP.modules.myModule.model.queries.add_some_data
DrupalAPP.modules.mySecondModule = {
        onLoad:function() {
                //Установка хуков, вызывается в момент подключения модуля только один раз
                //Для удаления хука достаточно будет отключить модуль и перестроить весь стек модулей в новой очередности.
                //Модули будут подниматься в память только один раз, вычисление хука становится более экономичным, все цепочки хуков будут выстраиваться при инициализации
                DrupalAPP.kernel.install_hook(
                        DrupalAPP.modules.mySecondModule.model.queries,
                        DrupalAPP.modules.myModule.model.queries,
                        "add_some_data"
                );
        },
        model : {
                queries: {
                        add_some_data:function(params, callback, target, method) {
                                //Вызвать parent method, причем парентом может оказаться чей то другой хук, для нас это не важно, сохранен принцип инкапсуляции.
                                method.call(target, params, function(result) {
                                        //ассинхронный вызов SQL
                                        db.query(..., function(resExt) {
                                                //merge resExt with result
                                                result = merge(resExt, result);
                                                callback(result);
                                        });
                                });
                        }
                }
        }
};

Многие пугаются этих ассинхронных вызовов, но во-первых речь идет только о IO calls, а во вторых все они на самом деле синхронизированы при помощи JavaScript event loop, просто существует очередь, в которую ставится очередной колбек, и вызываться они будут соответственно по принципу FIFO. При достаточной продуманности модульности архитектуры можно избежать глубоких монад и вложенностей.

Аватар пользователя bratello
bratello 6 лет назад

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

Аватар пользователя Shift-Web
Shift-Web 6 лет назад
bratello написал:
Я вот думаю

А Вы не думайте ;)

p.s.: Я вот смотрю на код и в общем спасибо. Подкинули идейку.

Аватар пользователя bratello
bratello 6 лет назад
Shift-Web написал:
Подкинули идейку.

За идейку не за что, их есть у меня.

Кстати предыдущий пример с инсталляцией и вызовом хука можно еще немного упростить:

DrupalAPP.kernel.install_hook = function(source, target, hookName) {
        var hooked = target[hookName];
        target[hookName] = function() {
                var args = [].slice.call(arguments);//получить аргументы функции
                args.push((function(){
                        hooked.apply(target, arguments);
                }));
                source[hookName].apply(source, args);
        };
};

И тогда сама реализация хука будет выглядеть проще, не нужно заботиться о том чтобы передать правильный this в 'parent', в замыкании будет подставляться правильный this автоматически:

DrupalAPP.modules.mySecondModule = {
        model : {
                queries: {
                        add_some_data:function(params, callback, parent) {
                                //Call 'parent'
                                parent(params, function(result) {
                                        //ассинхронный вызов SQL
                                        db.query(..., function(resExt) {
                                                //merge resExt with result
                                                result = merge(resExt, result);
                                                callback(result);
                                        });
                                });
                        }
                }
        }
};

Нечто подобное можно видеть в express.js при вызове хуков.

На следующей неделе открою новый топик про node.js, возможно с express.js, от базовых вещей и теории event loop, до реализации конкарент серверов при помощи WebWorkers и других техник node.js fork. У меня на самом деле не большой опыт в node.js, с ним я разбираюсь всего неделю, но идеи эти засасывают как пылесос :-)

Аватар пользователя Shift-Web
Shift-Web 6 лет назад
bratello написал:
this автоматически:

Здесь не любят скобки (C) Кто-то в феске

Аватар пользователя bratello
bratello 6 лет назад

Энди, какие наброски?? Если 8-ка выйдет с таким же количеством багов как и 7-ка, то на Дрю можно будет ставить крест. Сейчас самое время публику загонять на уборку картошки и мигом фиксить баги, а все новые наброски отложить в сторону. Иначе проект потеряет фокусировку. Уже поговаривают о полной перекройке ядра ввиду взаимной связаности модулей и перегруженности System.

Я еще немного посмотрю и если речь дойдет до перекройки то предложу переезжать на node.js server side и full web 2.0 client side (backbone.js, underscore, client side templates), надеюсь в русском комьюнити достаточно людей с трезвым взглядом на вещи.

Аватар пользователя andypost@drupal.org
andypost@drupal.org 6 лет назад
bratello написал:
Я еще немного посмотрю

Дык нужно не смотреть, а действовать :) Кто мешает фиксить баги или переходить хоть на .Net?

Аватар пользователя bratello
bratello 6 лет назад

Религия мешает :-) В дрю мне нравится архитектурный подход, в частности NODE API. Но отсутствие хорошо спланированого аппликационного уровня меня останавливает от серьёзной работы над Drupal. Дрис это видимо тоже давно понимает, воркэраунды и вставки логики на уровне темы стали вылезать боком - архитекторы приходят к мысли о глубоком рефакторинге. Но если взвесить количество работы для того чтобы получить правильный Дрю, который откровенно говоря никогда не будет дружить с Web 2.0, постоянная борьба за производительность вместо того чтобы решать прикладные задачи (которая корнями уходит в производительность PHP runtime) - все эти вещи навевают логичный вопрос "А не пора ли менять технологический стэк?".

У node.js есть очевидное преимущество - этот рантайм идеально предназначен для создания на нем REST based Application Layer, открывается отличная перспектива для развития интеграций со сторонними аппликациям (for both Web based & mobile based). В паре с javascript based client side MVC (e.g. backbone.js + mustache.js template processor) получается одностраничный Modern Web APP. А если учесть что backbone.js совершенно не проблематично использовать и на стороне node.js сервера тоже, то связка эта будет гарантировать правильный контент для crawlers тоже. Вобщем я не вижу причины почему нужно вкладывать огромные усилия в заведомо отстающие технологии.

Аватар пользователя UnnamedNETUA
UnnamedNETUA 6 лет назад
bratello написал:
Религия мешает.....

Уже все сделали http://calip.so/dox#core На node.js, есть даже таксономия

Аватар пользователя andypost@drupal.org
andypost@drupal.org 6 лет назад

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

Аватар пользователя bratello
bratello 6 лет назад

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

Аватар пользователя bratello
bratello 6 лет назад

Сначала я надеялся что ситуация улучшится в 6-й версии, потому думал что 7-я это решение всех проблем. Теперь я вижу что проблем с каждой версией становится все больше и больше. Энди наверное скажет что мол нечего ждать - бери и чини. Но для меня не приемлимо заниматься инфраструктурами ядра, специфика моей задачи, которую я хочу интегрировать с друпалом, и без того не простая, нет возможности отвлекаться на инфрастуктурные вещи, иначе это превратится в долгострой.

Аватар пользователя iHappy
iHappy 6 лет назад

Ничем не буду помогать. даже не буду думать об этом. Есть чем заниматься и помимо этого)

Аватар пользователя novichekd
novichekd 5 лет назад

Интересно, а когда выйдет восмерка?

Аватар пользователя epagil
epagil 5 лет назад

Однако, связанные с ней шаблоны zennoposter события до сих пор не получили должного Search рассмотрения

Аватар пользователя Crea
Crea 5 лет назад

всем друпалерам изучать симфони...бугага