desperado я рассматриваю другую ситуацию...
1. Системы с подобным контролем доступа подразумевает невозможность ее обхода( дыры реализации не рассматриваются ) Иначе грош ей цена, это просто загрузка ресурсов левой и не нужной никому работой.
2. Если все рвно модуль надо чекать на совместимость, иожет просто прекратить пытаться им управлять из ядра, а просто чекать при подключении ?
3. Ядро с определением запроса и имяни модуля это скрипт в 2 switch в самом сложном варианте.
4. Как интересно ядро умеет определить, что за данные дать модулю, кроме параметров, которые дал юзер. Модуль таки просит их сам. Уверяю вас ни один алгоритм не даст вам возможности заранее узнать, что за данные захочет модуль если он сложнее ленты навостей, да и то частный случай, на основе которого строят CMS.
5. Вы идете здесь на страшный компромис. Говоря, что вообщем-то инфа недоступна всем подряд, ее даст ядро. С одной стороны готов согласиться, что если модуль пользуется только API ядра для запроса данных из базы и их созранения, то вы обеспечите эту самую безопасность... но тут вы резко и 100% отрежите яйца нормальному общению с базой с точки зрения скорости и построения SQL запроса.
6. Я всегда удивлялся, почему CMS/PHP такик страшно тормознутые, но после тога как начал читать и пробовать писать мелкие примеры, понял... основы для этого две. Первая - лень оптимизировать решения других систем, и слепое копирование методологии. Вторая желание создателей почуствовать себя большими, т.е. написать Windows/*nix на php. Это не оскарбление, это просто непонимание зачем забивать шурупы кувалдой.
7.Вообщем мне так и не стало понятно за последние 6 месяцев, зачем надо управлять данными в которых нифига не понимаем ? Я не знаю как написать точнее, лучше разделять и властвовать, т.е. определили модуль, подготовили юзер инфо, входные юзер данные, дали классы для темплейтов и унифицированного доступа в базу, на крайняк, если так секретно все, каждый модуль работет со свое базой, и пусть себе творит там все что хочет и как хочет, в такой ситации если модуль порит базу, то только свою а не соседних модулей... упали новости ну фиг с ними, но остальное цело. и главное скорость работы в десятки и даже сотни раз больше.
И последнее Мелкомягкие дали отличную идею Doc & View. Если View умеет показать, то может и отредактировать, а обновлением базы дело модуля. Потому сразу предупреждаю вопрос о редактировани данных через CMS ровно как и об их администрировании.
Вообщем если появиться реализация моего концепта, тогда и наверное у меня будет конкретный материал на котором можно будет играться. А пока это все очень умозрительно, я это понимаю, потому наверное и читаю все что попадается, что бы выбрать все самое лучшее....
Ядро может само игнорировать только тогда, когда уверенно может сказать что там твориться, да можно сделать так что все что можно изменить станет объектом зарегистрированным в системе, ну а теперь вы себе хоть примерно представляете что будет после того как вы попробуете написать 3 язычный портал ? с 1000 зарегистрированных пользователей ? где не только есть языковые пакеты, но и динамические поля, например, название или описание продукта ? и где список продуктов 1 000-10 000 штук ? одна только попытка вывесьт список товаров будет требовать такое колличесво ресурсов, что никакой кеш не спасет. тривиальная страница с 17 товарами генерилась от 0,5 до 1.2 сек.