Re[6]: Блоки, вики и т.п. - Nemerle

В последнее время народ стал постоянно поднимать вопрос блогов, вики и других новомодных новоротов для немерла.

Выскажу свое мнение.

Главное что мне категорически не нравится — это если информация по немерлу начнет разъезжаться по разным сакйтам.

У нас и так есть гугл-код и nemerle.org живущий на железе рсдн.

Проблемы nemerle.org связаны с тем, что мы перенесли юниксовое окружение в виндовую среду. Наверно это дело можно победить, но вот стоит ли?

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

Собственно идея...

Так вот все эти мысли на самом деле пересекаются с мыслями команды РСДН которые возникали у ее членов много раз на протяжении последних 5-7 лет.

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

Для многих идея которую я выскажу ниже может показаться крамольной, но по сути в интеренете все интересное — это форум

.

Конечно "форум" не в прямомо смысле, а в смысле общей формы — тема + обсуждение. Ведь так устроены и блоги, и форумы, и даже статьи (на хороших стайтах).

Что касается вики, то вики состоит из трех аспектов:
1. Движок форматирования текста.
2. Движок поддержки версионнсоти.
3. Движок поддержки безопасности.

Собственно форматирование и безопасность — это неотъемлемая часть форумных движков. Таким образом нам нужно добавить только поддержку версионности для всех сообщений в форумах. Ко всему прочему это даст возможность менять сообщения их авторами после их публикации, что тоже очень полезно.

Учитывая, что немерл сейас переживает волну интузиазма и то что у нас появилась (точнее появляется) движок NRails, можно было бы залудить проект модернизации RSDN.RU.

Общий план мне видится таким:
1. Реализация версионности сообщений форумов.
2. Реализация возможности правки отдельных разделов в сообщениях (если таковые имеются), как это делается в вики-движках.
3. Доработка или переработка реализации защиты на форумах с тем, чтобы она позволяла совместное владение одним сообщением несколькими человеками (для организации совместной работы над вики-контентом и статьями).
4. Переработка поддержки тегов с тем, чтобы на их базе можно было реализовать виртуальные форумы (содержащие темы и отдельные сообщения по конкретной тематике).
5. Создание пользовательского интерфейса позволяющего формировать блоги, раздел статей (аля вики) и виртуальные форумы.
6. Допиливание фич характерных для блогов (если оно вообще кому-то будет нужно).

При этом блогами можно считать некие виртуальные авторские (принадлежащие конкретным авторам) форумы.

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

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

Как дополнительную опцию можно перевести форматер РСДН-на на PegGrammar. Это позволит сделать его декларативнее, мощнее (PEG в сто раз мощнее регулярных выражений используемых сейчас) и эффективнее (с прекомпиляцией в компайлтайме).

ЗЫ

Вопрос в том кто есть ли желающие взяться за такую работу?

Естественно, что средством реализации будет немерл и NRails.

Здравствуйте, VladD2, Вы писали:

VD>Главное что мне категорически не нравится — это если информация по немерлу начнет разъезжаться по разным сакйтам.

VD>У нас и так есть гугл-код и nemerle.org живущий на железе рсдн.

Предложения в основном направлены на оживление nemerle.org, который по работоспособности сейчас очень напоминает кирпич.

VD>Проблемы nemerle.org связаны с тем, что мы перенесли юниксовое окружение в виндовую среду. Наверно это дело можно победить, но вот стоит ли?

VD>Мне кажется багтреккер и вики нужно перенести на гугль-код. Что касается блогов, тут вопрос особый, так как я не вижу того кто будет их писать. И уж точно мне не нравится идея использования третих сайтов для этого.

Нужен сайт для получения базовой информации по языку для человека, которого не интересует баг-трекер, блоги и так далее. nemerle.org эту функцию исполнял до недавнего времени, когда, по большому счёту, его стало невозможно редактировать.

VD>Учитывая, что немерл сейас переживает волну интузиазма и то что у нас появилась (точнее появляется) движок NRails, можно было бы залудить проект модернизации RSDN.RU.

Шикарно. Но nemerle.org != rsdn.ru.

VD>Общий план мне видится таким:
VD>1. Реализация версионности сообщений форумов.
VD>2. Реализация возможности правки отдельных разделов в сообщениях (если таковые имеются), как это делается в вики-движках.
VD>3. Доработка или переработка реализации защиты на форумах с тем, чтобы она позволяла совместное владение одним сообщением несколькими человеками (для организации совместной работы над вики-контентом и статьями).
VD>4. Переработка поддержки тегов с тем, чтобы на их базе можно было реализовать виртуальные форумы (содержащие темы и отдельные сообщения по конкретной тематике).
VD>5. Создание пользовательского интерфейса позволяющего формировать блоги, раздел статей (аля вики) и виртуальные форумы.
VD>6. Допиливание фич характерных для блогов (если оно вообще кому-то будет нужно).

Это все прекрасно. Вообще, некая абстрактная «деревянная» система контента, сдобренная под конкретный вид общения (блоги, форумы, вики) выглядит хорошим решением в плане принципа DRY.

Очень желательна ещё функциональность в формате Stack Overflow: интерактивные вопросы и ответы. Её так же можно реализовать на подобной системе контента.

VD>Вопрос в том кто есть ли желающие взяться за такую работу?

Я вот пробую написать хороший браузер кода. Он будет удобен и для nemerle.org и для rsdn.ru. Любой .NET-овский веб-фреймворк сможет использовать его как внешнюю библиотеку. Но поскольку это мой первый серьезный проект не только на Nemerle но и по программированию вообще, я не уверен в результатах.

VD>Естественно, что средством реализации будет немерл и NRails.

NRails, насколько я понимаю сейчас на стадии поиска view-движка. То есть разрабатывать для него что-нибудь на данный момент невозможно. И ещё будет невозможно как минимум месяц. А вот ASP.NET MVC 2 — платформа в меру инновативная, Немерлом поддерживаемая, Микрософтом отлаженная. Но если народ хочет NRails, то пожалуйста

Хочу ещё раз обратить внимание, что имхо нужен самый базовый сайт на nemerle.org, который должен содержать обзор языка, существующую документацию и линки на гуглокод/рсдн/и т. д.

Здравствуйте, catbert, Вы писали:

C>Предложения в основном направлены на оживление nemerle.org, который по работоспособности сейчас очень напоминает кирпич.

На самом деле он очень даже работают. Но проблем хватает.

C>Нужен сайт для получения базовой информации по языку для человека, которого не интересует баг-трекер, блоги и так далее. nemerle.org эту функцию исполнял до недавнего времени, когда, по большому счёту, его стало невозможно редактировать.

Я же уже давал ссылку. Его вполне можно редактировать.

VD>>Учитывая, что немерл сейас переживает волну интузиазма и то что у нас появилась (точнее появляется) движок NRails, можно было бы залудить проект модернизации RSDN.RU.

C>Шикарно. Но nemerle.org != rsdn.ru.

Это не совсем так. Железо одно. И перевести nemerle.org на движок rsdn.ru впроле себе возможно, как в прочем и организовать русскоязычные сервисы в рамках rsdn.ru. А ДСН-ы — это дело десятое. Натянуть юрл на сервис ничего не стоит.

C>Очень желательна ещё функциональность в формате Stack Overflow: интерактивные вопросы и ответы. Её так же можно реализовать на подобной системе контента.

Что значит "интерактивные"?

C>Я вот пробую написать хороший браузер кода. Он будет удобен и для nemerle.org и для rsdn.ru. Любой .NET-овский веб-фреймворк сможет использовать его как внешнюю библиотеку. Но поскольку это мой первый серьезный проект не только на Nemerle но и по программированию вообще, я не уверен в результатах.

Уверенность — это главное в нашем деле. Я первой своей программой написал резидентную DOS-овскую программу (на С). Это было очень сложно даже для матерых гуру, а я все сделал просто читая учебную кнингу Фраловых. Правда код этот был достоин только помойки, но опыт оказался незабываемым.

VD>>Естественно, что средством реализации будет немерл и NRails.

C>NRails, насколько я понимаю сейчас на стадии поиска view-движка. То есть разрабатывать для него что-нибудь на данный момент невозможно. И ещё будет невозможно как минимум месяц.

Боюсь, что за месяц данный проект только обсуждения развернет.

К тому же движок в общем-то есть — это стандартный MVC2-двихок дотнета. Вопрос в том насколько в НРельсах его удастся причесать и обустроить.

C> А вот ASP.NET MVC 2 — платформа в меру инновативная, Немерлом поддерживаемая, Микрософтом отлаженная. Но если народ хочет NRails, то пожалуйста

А NRails на нем и планируется базировать. Более того в тестовом проекте он и используется.

C>Хочу ещё раз обратить внимание, что имхо нужен самый базовый сайт на nemerle.org, который должен содержать обзор языка, существующую документацию и линки на гуглокод/рсдн/и т. д.

Повторяться не буду. Выше все сказано.

Здравствуйте, catbert, Вы писали:

C>NRails, насколько я понимаю сейчас на стадии поиска view-движка. То есть разрабатывать для него что-нибудь на данный момент невозможно. И ещё будет невозможно как минимум месяц. А вот ASP.NET MVC 2 — платформа в меру инновативная, Немерлом поддерживаемая, Микрософтом отлаженная. Но если народ хочет NRails, то пожалуйста

NRails это надстройка над ASP.NET MVC 2. Поиск движка идет, но он не помешает использовать стандартный aspx.

Здравствуйте, VladD2, Вы писали:

VD>Конечно "форум" не в прямомо смысле, а в смысле общей формы — тема + обсуждение. Ведь так устроены и блоги, и форумы, и даже статьи (на хороших стайтах).

Это Google Wave. Но его пока мало кто понимает.

VD>... Таким образом нам нужно добавить только поддержку версионности для всех сообщений в форумах. Ко всему прочему это даст возможность менять сообщения их авторами после их публикации, что тоже очень полезно.

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

VD>При этом блогами можно считать некие виртуальные авторские (принадлежащие конкретным авторам) форумы.

+1.
Вот эта идея очень хорошая. Когда давно заводил блог — было такое желание, но движок не позволяет.
Кстати, это фича будет уникальна: если все существующие на данный момент ресурсы предлагают только площадку + движок для форума, то данная фича предлагает площадку + движок + кучу гарантированных читателей.

Здравствуйте, VladD2

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

)
Ещё бы добавить указание типов сообщений, чтобы можно было затем расширять плагинами функциональность (грубо говоря, чтобы желающие могли плагинами добавлять форматирование latex для формул и всё что угодно, вплоть до компилятора прямо в теме форума)

Мне уже давно такая штука нужна, но всё никак не могу начать сам работать — уж больно много делать (я, правда, на php собирался)

Здравствуйте, Real 3L0, Вы писали:

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

На StackOverflow можно и сообщения корректировать. Вроде никто особо не жалуется

Главное — чтобы фронт-енд удобным был.

Здравствуйте, FDSC, Вы писали:

FDS>Неплохие предложения, особенно если бы движок можно было бы использовать не только на самом rsdn, но и на других сайтах (а лучше, и на Linux-хостингах

)

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

FDS>Ещё бы добавить указание типов сообщений, чтобы можно было затем расширять плагинами функциональность (грубо говоря, чтобы желающие могли плагинами добавлять форматирование latex для формул и всё что угодно, вплоть до компилятора прямо в теме форума)

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

FDS>Мне уже давно такая штука нужна, но всё никак не могу начать сам работать — уж больно много делать (я, правда, на php собирался)

Ну, вот если желающие заняться таким проектом найдустя, то можешь примкнуть к команде и воплотить свою мечту в жизнь.

Здравствуйте, VladD2, Вы писали:

VD>Тип сообщений тоже планировался, только не для "latex для формул", так как такие вещи нужны во всех типах, а для того чтобы для статей, сообщений и блогов омжно было бы сделать разную морду лица. Например, для статей нужно оглавление.

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

FDS>>Мне уже давно такая штука нужна, но всё никак не могу начать сам работать — уж больно много делать (я, правда, на php собирался)

VD>Ну, вот если желающие заняться таким проектом найдустя, то можешь примкнуть к команде и воплотить свою мечту в жизнь.

Ну да, если наконец смогу нормально программировать на Nemerle

ответь плиз на http://www.rsdn.ru/forum/nemerle/3812194.1.aspx
с движком надо определяться как можно скорее, есть вероятность, что я начну рабочий проект на nrails, он не будет опенсорсным, но рельсы обкатать поможет.

начинать без движка очень не хочется.
можно конечно совсем отделить морду от контроллеров, и морду писать на spark+c#, но при этом я предвижу проблем больше чем удобств.
еще вариант — юзать aspx, но они заразы валят мне студию.
третий вариант, юзать nhaml с указанием класса и методов, но мне будет трудно убедить команду, что это круче aspx (я сам в этом сомневаюсь).

вобщем куда ни кинь, всюду клин получается. надо понять что будет лучше работать:

допиленный интелисенс (не работает без класса и глючит в режиме indent) или допиленный интеллисенс для поддержки внешних DSL.

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

Здравствуйте, FDSC, Вы писали:

FDS>Ну да, ты прав. У меня там просто немного другая концепция была: грубо говоря, сообщения могли состоять из сообщений, получалось, что одно сообщение как бы представляет поток других сообщений (например, строк кода, которые можно комментировать и менять по отдельности). Так что это у меня просто мысли перепутались.

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

VD>>Ну, вот если желающие заняться таким проектом найдустя, то можешь примкнуть к команде и воплотить свою мечту в жизнь.

FDS>Ну да, если наконец смогу нормально программировать на Nemerle

Все должно быть наоборот. Сначала берешься за решение задачи, а потом, в процессе работы над этой задачей, осваиваешь немерле. Вот бери пример с Ziaw. Он за месяц очень прилично освоил Немерл. Причем я ему практически не подсказывал. Так что можно сказать, что он самоучка.

Здравствуйте, VladD2, Вы писали:

VD>Ясно. Это как в вики.
VD>Мне кажется, что для подобных вещей нужно просто ввести разделы в рамках одного сообщения. Причем фича эта должна быть чисто виртуальная, так как хранить конечно же проще все сообщение целиком. Тут ведь очень важна эффективность. Ведь сообщения еще нужно уметь быстро найти, отформатировать и отдать клиентам.

Видимо, у меня немного задача по другому стояла. Потому что составные сообщения можно кэшировать (т.е. генерировать их при изменении внутренних сообщений), а вот если нужно, например, осуществить поиск только по формулам latex или автоматически определить, какие страницы ссылаются на данную и обратно, то 1. придётся разбирать сохранённый код раздела, чтобы найти в нём все ссылки или формулы, 2. непонятно каким образом хранить метки, что на данную строку другие сообщения ссылаются (у меня просто это надо было делать)

VD>Все должно быть наоборот. Сначала берешься за решение задачи, а потом, в процессе работы над этой задачей, осваиваешь немерле. Вот бери пример с Ziaw. Он за месяц очень прилично освоил Немерл. Причем я ему практически не подсказывал. Так что можно сказать, что он самоучка.

А если задачу завалишь да ещё испортишь что-нибудь?
Да и у меня за месяц даже C# не освоился в своё время... наверное, я менее способный

Здравствуйте, Ziaw, Вы писали:

Z>ответь плиз на http://www.rsdn.ru/forum/nemerle/3812194.1.aspx
Z>с движком надо определяться как можно скорее, есть вероятность, что я начну рабочий проект на nrails, он не будет опенсорсным, но рельсы обкатать поможет.

Ответил.

Z>еще вариант — юзать aspx, но они заразы валят мне студию.

Это просто надо воспроизвести и поправить.

Z>третий вариант, юзать nhaml с указанием класса и методов, но мне будет трудно убедить команду, что это круче aspx (я сам в этом сомневаюсь).

Поглядел... Это точное не замечательный вариант.

Z>вобщем куда ни кинь, всюду клин получается. надо понять что будет лучше работать:

Я тебе в ответе описал свое видение. Единственной проблемой в его реализации будет, то что готового взять будет ничего нельзя. Разве что парсинг можно сделать с помощью PegGrammar. Но зато плюсами является все остальное.

Z>допиленный интелисенс (не работает без класса и глючит в режиме indent) или допиленный интеллисенс для поддержки внешних DSL.

К сожалению indent-эйшон-синтаксис практически не работает в IDE. Им попросту никто не занимался.

Z>все это надо сделать достаточно быстро, если через неделю не будет понятно, как все будет работать мне придется начинать проект без рельс, перевести туда потом, сам понимаешь, будет нереально.

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

Если не выпендриваться, то с применением PegParser у тебя на его реализацию уйдет где-то 1-2 недели. В худшем случае месяц.

Здравствуйте, FDSC, Вы писали:

FDS>Видимо, у меня немного задача по другому стояла. Потому что составные сообщения можно кэшировать (т.е. генерировать их при изменении внутренних сообщений), а вот если нужно, например, осуществить поиск только по формулам latex или автоматически определить, какие страницы ссылаются на данную и обратно, то 1. придётся разбирать сохранённый код раздела, чтобы найти в нём все ссылки или формулы, 2. непонятно каким образом хранить метки, что на данную строку другие сообщения ссылаются (у меня просто это надо было делать)

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

FDS>А если задачу завалишь да ещё испортишь что-нибудь?

Если делаешь ее только ты, то значит твоя задача завалится. Плохо конечно, но вряд ли кто-то обидится.
Если работаешь внутри коллектива, то есть те кто будет тянуть лямку.
Так что основная проблема не вредить сильно. Как показывает практика — это совершенно реально.

FDS>Да и у меня за месяц даже C# не освоился в своё время... наверное, я менее способный

Дык он немерл именно после C# осваивал. С нуля конечно — это не реально.

Здравствуйте, VladD2, Вы писали:

VD>Если не выпендриваться, то с применением PegParser у тебя на его реализацию уйдет где-то 1-2 недели. В худшем случае месяц.

Этот проект не может ждать месяц, тот же спарк я прикручу дня за 3-4, и посажу людей за работу, а сам начну мучать комплишен. С хамлом сроки чуть длиннее, но меньше потом проблем с комплишеном.

Здравствуйте, VladD2, Вы писали:

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

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

VD>Дык он немерл именно после C# осваивал. С нуля конечно — это не реально.

Ну я ведь Nemerle больше месяца на реальных задачах точно программировал — и так не научился. Если не знаешь как (к тому же, я торопился), фигово получается: код дурацкий, преимуществ никаких.

Здравствуйте, Ziaw, Вы писали:

Z>Этот проект не может ждать месяц, тот же спарк я прикручу дня за 3-4, и посажу людей за работу, а сам начну мучать комплишен. С хамлом сроки чуть длиннее, но меньше потом проблем с комплишеном.

Я же сказал "в худшем". Твои 3-4 дня так же в худшем случае выльются в месяц, а то и более.

VD>Что касается вики, то вики состоит из трех аспектов:
VD>1. Движок форматирования текста.
VD>2. Движок поддержки версионнсоти.
VD>3. Движок поддержки безопасности.

Это не ключевые особенности вики.

Вики состоит из одного аспекта:
— там находятся статьи про термины и эти термины пролинкованы между собой.

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

Также, очень жалею, что в вики нет возможности редактировать иерархические классификаторы и привязывать их к топикам,
а так же, что добавлять ссылки на термины все-таки надо вручную (этот процесс недостаточно автоматизирован).

Здравствуйте, Arsen.Shnurkov, Вы писали:

AS>Вики состоит из одного аспекта:
AS> — там находятся статьи про термины и эти термины пролинкованы между собой.

AS>Технически, сообщения в форуме позволяют делать ссылки, но это не то же самое, что в вики.

Это мелкий технический аспект. Таких аспектов будет не мало для каждого типа контента. Но общую идеологию это не ломает.

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

Сделать для страницы уникальное имя-URL не составляет труда.

AS>Также, очень жалею, что в вики нет возможности редактировать иерархические классификаторы и привязывать их к топикам,

Вот эту задачу и должны решать иерархические теги.

AS>а так же, что добавлять ссылки на термины все-таки надо вручную (этот процесс недостаточно автоматизирован).

Ну, если будет описанный мной движок, то сделать автоматизацию процесса создания ссылки не составит труда.

Здравствуйте, VladD2, Вы писали:

VD>Главное что мне категорически не нравится — это если информация по немерлу начнет разъезжаться по разным сакйтам.

Я предложил это, потому что это google-way, рекомендованный самим гуглем для проектов на гуголкоде: код, трекер и вики на самом гуглокоде, блог на блогспоте, сложная документацих на гуглодоках, если чего надо заскриптовать, то питон/ява на гуглоаппах. И все это собирается в один домен и снаружи выглядит как один сайт. Но "гуглозависимость" получается 100%-ая. Мне тоже не нравится идея разнесения проекта по сайтам, даже в случае с гуглокодом. Кстати, а почему его вынесли туда?

VD>Мне кажется багтреккер и вики нужно перенести на гугль-код.

Насчет вики не уверен, что стоит. Изучая документацию к гуглокоду, я где-то в недрах наткнулся на упоминание того, что страницы той вики плохо индексируются и имеют низкий pagerank. Т.е. она рекомендуется только для хранения непосредственной проектной документации (ну там, как собрать проект, интеграцию, API компилятора, соглашение о кодировании) и т.п. Есть подозрение, что если мы вики перенесем туда, то на эту инфу через поисковые запросы будет крайне тяжело попасть, в то время как nemerle.org сейчас индексирован очень даже неплохо.

VD>Так вот все эти мысли на самом деле пересекаются с мыслями команды РСДН которые возникали у ее членов много раз на протяжении последних 5-7 лет.

Я тут весь сегодняшний день убил на изучение протоколов пересечения мыслей команды RSDN в 2007 году по данному вопросу, и мне кажется, что проект нового движка стоит делать открытым полностью, но инфу о текущем движке по возможности не открывать, либо открывать по-минимуму. Что делать с безопасностью в этом случае я знаю, а вот что делать, если кого-то из участников проекта нового движка не возьмут в тим, либо опять начнутся "пересечения мыслей" — я хз.

И у меня совершенно нет понимания того, как лучше это внедрять здесь, коль скоро до этого дойдет. Таки-поэтапно, по ходу разработки нового движка (но это сильно затормозит процесс разработки) или единовременной миграцией после того, как новый движок будет не менее функционален чем старый или запуском двух движков параллельно в режиме интеграции с постепенным перетягиванием функционала от одного к другому? В любом случае, по оптимистичным прогнозам (твоим, в тимовском форуме) на это уйдет не меньше года, а пессимисты вон утверждают, что и все пять лет. Ок, пять человеко-лет, но это все равно очень большой срок, в течении которого nemerle.org будет находится в том состоянии, в котором он находится сейчас. Т.е. либо все-таки переносить вики на гуглокод и пока завернуть nemerle.org туда, либо крайне быстро реализовывать минимальное ядро нового движка в расчете на скорый перенос под него контента с nemerle.org, а уже потом допиливать это ядро до нужного функционала, либо что-то третье типа временного использования левого вики-движка (но это — куча лишних телодвижений) —

VD>3. Доработка или переработка реализации защиты на форумах с тем, чтобы она позволяла совместное владение одним сообщением несколькими человеками (для организации совместной работы над вики-контентом и статьями).

Собственно этим я готов заняться. У меня есть наработки по декларативному движку разграничения пользовательских полномочий в .NET приложениях (иерархический RBAC с уклоном в MAC), он вполне себе впишется в NRails. В принципе, его можно оформить и как отдельный проект, с тем, чтобы использовать и в других приложениях. Либо допилить до его уровня текущую реализацию модели безопасности — это сложнее, но тоже возможно.

Ну и традиционный "maintaining" вполне могу обеспечить.

VD>Как дополнительную опцию можно перевести форматер РСДН-на на PegGrammar. Это позволит сделать его декларативнее, мощнее (PEG в сто раз мощнее регулярных выражений используемых сейчас) и эффективнее (с прекомпиляцией в компайлтайме).

А вот этим, кстати, можно заняться уже сейчас, безотносительно планов по новому движку, IMHO. Правда тут я вряд ли чем-нибудь смогу помочь.

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV> Кстати, а почему его вынесли туда?

Надежность. Они и бэкапы делают постоянно. И сервис живет почти 24 * 7. В то время немерловый сервер жил реже чем лежал.

Потом еще с играл фактор боязни нас. Проект ведь изначально был поляков.

KV>...nemerle.org сейчас индексирован очень даже неплохо.

Сомневаюсь, что из-за индексации будут пробелмы.
Вот простой тест "NRails". Вроде никаких проблем.

KV>...мне кажется, что проект нового движка стоит делать открытым полностью,

Можно и так.

KV>Что делать с безопасностью в этом случае я знаю, а вот что делать, если кого-то из участников проекта нового движка не возьмут в тим, либо опять начнутся "пересечения мыслей" — я хз.

Думаю этот вопрос мы утрясем, если что. Так что это тоже не проблема.

KV>Таки-поэтапно, по ходу разработки нового движка (но это сильно затормозит процесс разработки)

Только так.

KV>или единовременной миграцией после того, как новый движок будет не менее функционален чем старый

Это практически означает, что перехода не будет никогда.

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

KV> или запуском двух движков параллельно в режиме интеграции с постепенным перетягиванием функционала от одного к другому?

Именно так. Хотя я тут не вижу разницы с первым вариантом. Это и есть поэтапный переход.

KV> В любом случае, по оптимистичным прогнозам (твоим, в тимовском форуме) на это уйдет не меньше года, а пессимисты вон утверждают, что и все пять лет.

Все упирается в защиту. Это самая сложная часть. Если ты знаешь как такое реализовать, то остальное дело техники.

Важное не то за сколько весь сайт перелезет на новый движок. А то насколько быстро появятся первые бенефиты от этой работы. Например, викевость для статей, или блоги (пусть и без кроспостингов в основные форумы).

KV> Т.е. либо все-таки переносить вики на гуглокод и пока завернуть nemerle.org туда, либо крайне быстро реализовывать минимальное ядро нового движка в расчете на скорый перенос под него контента с nemerle.org, а уже потом допиливать это ядро до нужного функционала, либо что-то третье типа временного использования левого вики-движка (но это — куча лишних телодвижений) —

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

VD>>3. Доработка или переработка реализации защиты на форумах с тем, чтобы она позволяла совместное владение одним сообщением несколькими человеками (для организации совместной работы над вики-контентом и статьями).

KV>Собственно этим я готов заняться. У меня есть наработки по декларативному движку разграничения пользовательских полномочий в .NET приложениях (иерархический RBAC с уклоном в MAC), он вполне себе впишется в NRails. В принципе, его можно оформить и как отдельный проект, с тем, чтобы использовать и в других приложениях. Либо допилить до его уровня текущую реализацию модели безопасности — это сложнее, но тоже возможно.

Тут надо понимать, что основная проблема защиты в такой системе — это высокая производительность.

Гибкость гибкостью, но мы обязаны держать сотни параллельных запросов. Посему мы планировали делать защиту в виде связи таблиц. Но это тоже нагружает сервер.

Если у тебя есть видение как обеспечить гибкую защиту в купе с высокой производительностью (для выборок из БД), то можно сказать, что пол дела сделано.

Ну, а что такое RBAC и MAC я даже не знаю.

VD>>Как дополнительную опцию можно перевести форматер РСДН-на на PegGrammar. Это позволит сделать его декларативнее, мощнее (PEG в сто раз мощнее регулярных выражений используемых сейчас) и эффективнее (с прекомпиляцией в компайлтайме).

KV>А вот этим, кстати, можно заняться уже сейчас, безотносительно планов по новому движку, IMHO. Правда тут я вряд ли чем-нибудь смогу помочь.

Да. Но и на это нужно время. Ведь в процессе работы вылезут какие-то проблемы которые тоже надо будет устранить.

Здравствуйте, VladD2, Вы писали:

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, VladD2, Вы писали:

KV>> В любом случае, по оптимистичным прогнозам (твоим, в тимовском форуме) на это уйдет не меньше года, а пессимисты вон утверждают, что и все пять лет.

VD>Все упирается в защиту. Это самая сложная часть. Если ты знаешь как такое реализовать, то остальное дело техники.

Извини, а почему защита — это самое сложное? Вообще, под защитой имеются в виду права пользователей или что-то сильно другое?

VD>Тут надо понимать, что основная проблема защиты в такой системе — это высокая производительность.
VD>Гибкость гибкостью, но мы обязаны держать сотни параллельных запросов. Посему мы планировали делать защиту в виде связи таблиц. Но это тоже нагружает сервер.

А что, нельзя сохранять описатели прав прямо в статье или другой позиции хранения? Сервер же всё равно прочитает файл.

Здравствуйте, VladD2, Вы писали:

KV>> Т.е. либо все-таки переносить вики на гуглокод и пока завернуть nemerle.org туда, либо крайне быстро реализовывать минимальное ядро нового движка в расчете на скорый перенос под него контента с nemerle.org, а уже потом допиливать это ядро до нужного функционала, либо что-то третье типа временного использования левого вики-движка (но это — куча лишних телодвижений) —

Здравствуйте, FDSC, Вы писали:

FDS>Извини, а почему защита — это самое сложное? Вообще, под защитой имеются в виду права пользователей или что-то сильно другое?

Отсутствие уязвимостей одновременно с простотой логики (нагрузки высокие), а "аудит" на программерском форуме будет жесткий.

Здравствуйте, VladD2, Вы писали:

KV>>...nemerle.org сейчас индексирован очень даже неплохо.

VD>Сомневаюсь, что из-за индексации будут пробелмы.
VD>Вот простой тест "NRails". Вроде никаких проблем.

Это потому, что NRails редкое слово. Высокий page rank это наличие ссылок с других сайтов. А они все ведут на nemerle.org. Так что вики лучше оставить там.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, FDSC, Вы писали:

FDS>>Извини, а почему защита — это самое сложное? Вообще, под защитой имеются в виду права пользователей или что-то сильно другое?

Z>Отсутствие уязвимостей

Аааааа! Опять...

Защита != безопасность != отсутствие уязвимостей. Уязвимость — это точно такой же баг, как и любой другой, но позволяющий реализовать ту или иную информационную угрозу в нашей системе. Когда кто-то рассуждает об отсутствии багов, это почти всегда вызывает снисходительную улыбку у разработчиков, но они сами вполне серьезно рассуждают об отсутствии уязвимостей и верят в это

Мы как раз обсуждаем это здесь.

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, FDSC, Вы писали:

VD>>Все упирается в защиту. Это самая сложная часть. Если ты знаешь как такое реализовать, то остальное дело техники.
FDS>Извини, а почему защита — это самое сложное? Вообще, под защитой имеются в виду права пользователей или что-то сильно другое?

Да, в данном контексте речь идет о контроле доступа. Это не столько самое сложное, сколько одно из самых... ответственных что-ли. Т.к. ошибка, допущенная в нем на этапе дизайна 100% станет фатальной на этапе реализации, но при этом проявится может далеко не сразу.

FDS>А что, нельзя сохранять описатели прав прямо в статье или другой позиции хранения? Сервер же всё равно прочитает файл.

Файл хранит скорее представление статьи и доступ к нему разграничен через права доступа в соответствующий SVN-репозиторий. Т.е. изменение этого файла идет вообще мимо движка. А статья как объект контроля пользовательского доступа в движке является записью в таблице БД, ну или уровнем выше — объектом в терминах ООП. По крайней мере, так это реализовано сейчас.

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>> Кстати, а почему его вынесли туда?

VD>Потом еще с играл фактор боязни нас. Проект ведь изначально был поляков.

Я примерно так и думал. Ну, он и сейчас еще играет. Домен-то они не отдали, просто завернули на наши DNS

KV>> В любом случае, по оптимистичным прогнозам (твоим, в тимовском форуме) на это уйдет не меньше года, а пессимисты вон утверждают, что и все пять лет.
VD>Все упирается в защиту. Это самая сложная часть. Если ты знаешь как такое реализовать, то остальное дело техники.

KV>> Т.е. либо все-таки переносить вики на гуглокод и пока завернуть nemerle.org туда, либо крайне быстро реализовывать минимальное ядро нового движка в расчете на скорый перенос под него контента с nemerle.org, а уже потом допиливать это ядро до нужного функционала, либо что-то третье типа временного использования левого вики-движка (но это — куча лишних телодвижений) —

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

Да, наверное это лучший вариант.

VD>Если у тебя есть видение как обеспечить гибкую защиту в купе с высокой производительностью (для выборок из БД), то можно сказать, что пол дела сделано.

Из того, что я смог найти в обсуждениях, я понял что, вы планировали реализовать разграничение прав доступа таким образом, чтобы конечные CRUD-запросы приходили в СУБД уже с учетом полномочий текущего пользователя. Но это то, что будет у подсистемы контроля доступа на выходе, эдакий бэкенд, а вот описание фронтенда (какая модель доступа будет применяться для разграничения, как будет осуществляться выборка полномочий текущего пользователя для формирования запроса и т.п.) я так и не нашел

Это обсуждалось?

VD>Ну, а что такое RBAC и MAC я даже не знаю.

Это ролевой контроль доступа и принудительный контроль доступа — различные модели реализации такого контроля. Ролевой доступ (RBAC) — это то, что используется в текущем движке, все полномочия пользователя определяются исключительно его принадлежностью к какой-либо роли (аноним, юзер, модератор, админ, тимер и т.п.). В случае принудительного доступа (MAC), все объекты и субъекты контроля доступа снабжаются метками безопасности, в которых указана их принадлежность к тому или иному классу конфиденциальности и категориям классификации. Когда субъект пытается получить доступ к объекту, их метки сравниваются и на основе этого принимается решение о предоставлении доступа. MAC — единственная модель, безопасность которой может быть доказана математически.

Собственно пока, из того что я успел прочитать, я сделал вывод, что вы пытались интуитивно реализовать подобие MAC.

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Файл хранит скорее представление статьи и доступ к нему разграничен через права доступа в соответствующий SVN-репозиторий. Т.е. изменение этого файла идет вообще мимо движка. А статья как объект контроля пользовательского доступа в движке является записью в таблице БД, ну или уровнем выше — объектом в терминах ООП. По крайней мере, так это реализовано сейчас.

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

Здравствуйте, FDSC, Вы писали:

FDS>Извини, а почему защита — это самое сложное? Вообще, под защитой имеются в виду права пользователей или что-то сильно другое?

Это самое ответственное. Она больше всего просаживает производительность. Ну, и сделав ошибки в дизайне потом проблемы будут вылезать повсеместно.

FDS>А что, нельзя сохранять описатели прав прямо в статье или другой позиции хранения? Сервер же всё равно прочитает файл.

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

Здравствуйте, Ziaw, Вы писали:

Z>В проекте который я стартую на nrails понадобится вики. Я планировал использовать xwiki в качестве бэкэнда, но можно и свое написать, если будет какая-то поддержка снаружи. Писать викидвижок с нуля не очень рентабельно для проекта в 5-10 чел/мес.

Нам не нужна Вики как таковая. Нам нужна фунциональность вики в рамках единого движка. Любо тип контента в системе должен быть версионным и поддерживать форматирование (в плоть до подкраски синтаксиса в коде).

Форматирование у нас уже есть. Возможно его стоило бы переписать, но это уже отдельный вопрос. Главное, что этот код уже можно использовать и известен формат (тот что используется в сообщения РСДН-а).

Соответственно все готовые решения нам не подходят. Разве что для черпания идей.

Здравствуйте, VladD2, Вы писали:

Z>>В проекте который я стартую на nrails понадобится вики. Я планировал использовать xwiki в качестве бэкэнда, но можно и свое написать, если будет какая-то поддержка снаружи. Писать викидвижок с нуля не очень рентабельно для проекта в 5-10 чел/мес.

VD>Нам не нужна Вики как таковая. Нам нужна фунциональность вики в рамках единого движка. Любо тип контента в системе должен быть версионным и поддерживать форматирование (в плоть до подкраски синтаксиса в коде).

VD>Форматирование у нас уже есть. Возможно его стоило бы переписать, но это уже отдельный вопрос. Главное, что этот код уже можно использовать и известен формат (тот что используется в сообщения РСДН-а).

Просто я предлагал поработать над вики в рамках своего проекта. Условия такие — в течении недели нужна примерная архитектура расчтанная на итерационную разработку, при которой через 1-2 ч/мес получается рабочая вики годная для меня, вероятно она подойдет и для nemerle.org на этом этапе. После этого можно будет думать о том, смогу ли я дальше развивать эту вики один в свободное время или мне потребуются доп ресурсы. В итоге всеже получится даже не вики, а новый движок для рсдн. Продумывать архитектуру в любом случае придется, так что я не прошу каких-то доп усилий кроме как сделать возможность разработки в аджайл стиле. Свяжись с Синклайром, имхо, он в таких вещах спец и как старый рсдновец, возможно набросает архитектуру под MVC (схему данных, основные сервисы, принципы работы версионности, безопасность).

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Из того, что я смог найти в обсуждениях, я понял что, вы планировали реализовать разграничение прав доступа таким образом, чтобы конечные CRUD-запросы приходили в СУБД уже с учетом полномочий текущего пользователя. Но это то, что будет у подсистемы контроля доступа на выходе, эдакий бэкенд, а вот описание фронтенда (какая модель доступа будет применяться для разграничения, как будет осуществляться выборка полномочий текущего пользователя для формирования запроса и т.п.) я так и не нашел

Это обсуждалось?

Уже не помню.

Но тут ты пожалуй и сам все сможешь придумать.

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

KV>Это ролевой контроль доступа и принудительный контроль доступа — различные модели реализации такого контроля. Ролевой доступ (RBAC) — это то, что используется в текущем движке, все полномочия пользователя определяются исключительно его принадлежностью к какой-либо роли (аноним, юзер, модератор, админ, тимер и т.п.). В случае принудительного доступа (MAC), все объекты и субъекты контроля доступа снабжаются метками безопасности, в которых указана их принадлежность к тому или иному классу конфиденциальности и категориям классификации. Когда субъект пытается получить доступ к объекту, их метки сравниваются и на основе этого принимается решение о предоставлении доступа. MAC — единственная модель, безопасность которой может быть доказана математически.

Тогда нам нужен MAC (только не из математических сооражений), но так чтобы можно было все же оперировать составными токенами защиты.

KV>Собственно пока, из того что я успел прочитать, я сделал вывод, что вы пытались интуитивно реализовать подобие MAC.

Наверно. Как я уже говорил прототипом была защита NT. Она MAC?

Здравствуйте, Ziaw, Вы писали:

Z>Просто я предлагал поработать над вики в рамках своего проекта. Условия такие — в течении недели нужна примерная архитектура расчтанная на итерационную разработку, при которой через 1-2 ч/мес получается рабочая вики годная для меня, вероятно она подойдет и для nemerle.org на этом этапе.

Я тебе могу описать наши требования. А уж сможешь ли ты их совместить со своими я не знаю.

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

Синклер сайтом не занимался. Да и где он сейчас я не знаю.

Тут скорее нужна помощь IT и АВК. Хотя они могут снова переругаться.

Собственно функциональность которая нужна нами уже много раз обсуждалась и ее не трудно озвучить.

Первое что нужно — это версионная запись текста:
1. Если текста нет, то создается новая метазапись о нем и БЛОБ в БД или файл на диске. Мы так и не пришли к единому мнению что лучше.
2. Если текст есть, то нужно сделать diff этого текста и его новой версии и записать в БД новую версию и этот диф. По диф-у и тексту нужно иметь возможность получить предыдущую версию. В конечном итоге у нас должна храниться последняя версия целиком и набор дифов для всех изменений. На первых порах можно просто хранить все версии.

Второе — поддержка нашего форматера. Он доступен в отдельной сборке.

Третье — та самая защита. Обзор "сообщений" (назовем это так) должен быть доступен только тем кто входит в группы которым разрешен доступ и не входит в группы которым доступ запрещен.

Далее нужно иерархическая организация на базе тегов, но это уже довольно не простая тема. Ее нужно описывать отдельно. Там уже все упирается в механизмы защиты.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Файл хранит скорее представление статьи и доступ к нему разграничен через права доступа в соответствующий SVN-репозиторий. Т.е.

Сейчас файл хронит сообщение в формате RsdnML и лежит он на диске. То что его еще в SVN пихают не относится к функциональности сайта.

У SVN-а есть одна проблема. Он не сможет выдержать количества документов такого сколько у нас на форумах документов.

KV> изменение этого файла идет вообще мимо движка.
KV>А статья как объект контроля пользовательского доступа в движке является записью в таблице БД, ну или уровнем выше — объектом в терминах ООП. По крайней мере, так это реализовано сейчас.

+1

Здравствуйте, FDSC, Вы писали:

FDS>В новом движке, наверное, это будет не очень здорово: версионность и в самом движке, и в системе контроля версий...

Контроль версий должен устранить необходимость в использовании SVN. Сейчас он используется чтобы хоть как-то организовать хранение версий статей. Иначе потеря носителя приведет к потере всех статей.

Но SVN не может использоваться для форумов. Он просто ляжет от такой нагрузки.

Так что нужна единая версионная система.

Здравствуйте, VladD2, Вы писали:

VD>Я тебе могу описать наши требования. А уж сможешь ли ты их совместить со своими я не знаю.

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

Здравствуйте, Ziaw, Вы писали:

VD>>Я тебе могу описать наши требования. А уж сможешь ли ты их совместить со своими я не знаю.

Z>Требования вполне совместимы с моими, осталось набросать архитектуру. Если мне придется делать ее самому — хочу от тебя обещания, что вместо обвинения ее в кривоте и позорном желании использовать готовое компоненты вместо написания всего с нуля ты просто не будешь юзать вики.

А зачем тут какие-то обещания? Все очень просто. Если твое решение нас по каким-то причинам не устроит, то мы сможем сделать только одно из двух поправить его для своих нужд или отказаться от него. Третьего не дано.

Z>Мне изрядно надоел стиль общения хренового учителя с нашкодившим учеником.

Ты не верно воспринимаешь критики. Ее нужно учитывать и извлекать из нее пользу. Смотри на нее как на информацию. Тогда она никогда не сможет тебя задеть.

В общем, если не хочешь слушать от меня замечания, то я могу просто молчать и отвечать только на узко технические вопросы.

Здравствуйте, VladD2, Вы писали:

KV>>Собственно пока, из того что я успел прочитать, я сделал вывод, что вы пытались интуитивно реализовать подобие MAC.
VD>Наверно. Как я уже говорил прототипом была защита NT. Она MAC?

Не сочти за издевательство, но NT — это DAC

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Не сочти за издевательство, но NT — это DAC

В чистом виде он не очень походит для веб-приложения, т.к. в этом случае (дискреционного доступа), владелец информации (тот, кто ее создал или получил во владение, если имел на это право) получает безграничный контроль над этой информацией. Но ACL'и, которые обсуждались на тимовском форуме — это как раз оттуда, да.

Владельцев мы не рассматривали. В нашем случае достаточно чтобы права могли менять админы. Нам важен именно аналог ACL. То есть некоторая хрень которая позволит быстро понять доступны для некоторого пользователя некоторые данные или нет.

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

ОК

Здравствуйте, VladD2, Вы писали:

VD>Тут скорее нужна помощь IT и АВК. Хотя они могут снова переругаться.
Вот именно. Так что не и, а или.
И лично я предпочту IT'а.

VD>1. Если текста нет, то создается новая метазапись о нем и БЛОБ в БД или файл на диске. Мы так и не пришли к единому мнению что лучше.
VD>2. Если текст есть, то нужно сделать diff этого текста и его новой версии и записать в БД новую версию и этот диф. По диф-у и тексту нужно иметь возможность получить предыдущую версию. В конечном итоге у нас должна храниться последняя версия целиком и набор дифов для всех изменений. На первых порах можно просто хранить все версии.
Тут ИМХО нужно делать так:
В базе нужно хранить только имена блобов.
Имя блобу дается исключительно на основе его содержимого.
SHA-256 ИМХО более чем достаточен чтобы обеспечить уникальность на практически любых объемах.
Содержимое блоба должно начинаться с флагов. Варианты которые сразу приходят на ум:
1)Блоб
2)Сжатый блоб
3)Патч
4)Сжатый патч

Как блобы хранить нужно подумать.
Тут полно вариантов.
1)Таже база где лежит метаинформация.
Этот вариант мне совсем не нравится. Ибо нагружать основную базу которая занимается кучей всяких кучерявых джойнов не дело.

2)Отдельная база для блобов.
Это лучше. Но всеравно одна база вызывает сомнения.

3)Файловая система и иерархией каталогов. Думаю два уровня по 3 шеснадцатиричных цифры будут в самый раз.
Очень хороший, проверенный временем и кучей дико нагруженных проектов вариант.
Но нам нужно атомарное обновление блобов. Тут с этим придется повозиться.

4)Куча мелких баз для блобов. Возможно использование какой ни будь встраиваемой СУБД типа SQLite. Думаю 3-4 цифры от хеша в качестве имени будут в самый раз.
Этот вариант ИМХО лучше всех ибо проблему с обновлением уже решил автор БД.
Также кучу мелких баз можно по одной упаковывать практически не создавая нагрузки.

Кстати использование хешей для имени блобов решает еще одну задачу: А именно делает кеширование тривиальным. Ибо однажды обработанный блоб можно закешировать навсегда.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, WolfHound, Вы писали:

WH>Вот именно. Так что не и, а или.
WH>И лично я предпочту IT'а.

+1

Здравствуйте, WolfHound, Вы писали:

WH>3)Файловая система и иерархией каталогов. Думаю два уровня по 3 шеснадцатиричных цифры будут в самый раз.
WH>Очень хороший, проверенный временем и кучей дико нагруженных проектов вариант.
WH>Но нам нужно атомарное обновление блобов. Тут с этим придется повозиться.

Атомарность обновления можно сделать путем запихивания запросов на редактирование в очередь. Все равно как такового параллельного редактирования по сути не будет.

WH>4)Куча мелких баз для блобов. Возможно использование какой ни будь встраиваемой СУБД типа SQLite. Думаю 3-4 цифры от хеша в качестве имени будут в самый раз.
WH>Этот вариант ИМХО лучше всех ибо проблему с обновлением уже решил автор БД.
WH>Также кучу мелких баз можно по одной упаковывать практически не создавая нагрузки.

Тут сразу нужно думать о бэкапе данных. Как ты представляешь себе бэкап кучи мелких БД? Да и зачем тогда куча то?

WH>Кстати использование хешей для имени блобов решает еще одну задачу: А именно делает кеширование тривиальным. Ибо однажды обработанный блоб можно закешировать навсегда.

А кому он нужен то? Нужны конечные версии страниц.

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

Так что рассматривать нужно два варианта. Одна БД для блобов или файлы.

Кастанул заклинание призыва IT в эту тему. Хз когда подействует и подействует ли... Подождем

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Кастанул заклинание призыва IT в эту тему. Хз когда подействует и подействует ли... Подождем

У него там сейчас на работе аврал.

Здравствуйте, VladD2, Вы писали:

VD>Естественно, что средством реализации будет немерл и NRails.

А что насчёт Nemerle и FW 4.0? Не хотелось бы использовать старую версию фреймворка в таком проекте.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Это ролевой контроль доступа и принудительный контроль доступа — различные модели реализации такого контроля. Ролевой доступ (RBAC) — это то, что используется в текущем движке, все полномочия пользователя определяются исключительно его принадлежностью к какой-либо роли (аноним, юзер, модератор, админ, тимер и т.п.). В случае принудительного доступа (MAC), все объекты и субъекты контроля доступа снабжаются метками безопасности, в которых указана их принадлежность к тому или иному классу конфиденциальности и категориям классификации. Когда субъект пытается получить доступ к объекту, их метки сравниваются и на основе этого принимается решение о предоставлении доступа. MAC — единственная модель, безопасность которой может быть доказана математически.

KV>Собственно пока, из того что я успел прочитать, я сделал вывод, что вы пытались интуитивно реализовать подобие MAC.

Скорее мы пытались интуитивно использовать обе модели. С одной стороны нам нужно разделение прав доступа к ресурсам (видимо это MAC), с другой разделение прав доступа к определённым действиям (это роли). Обе модели реализуются по разному и практически не пересекаются. Если для ролей есть вполне приличная поддержка со стороны ASP.NET, то для управления доступом к ресурсам нужно придумывать свою схему и здесь важна в первую очередь производительность. А учитывая, что у нас почти 4 миллиона сообщений и около 100 тысяч пользователей в базе, то в лоб такая задача плохо решается.

Здравствуйте, VladD2, Вы писали:

VD>Тут скорее нужна помощь IT и АВК. Хотя они могут снова переругаться.

Мы уже давно научились с АВК не ругаться.

VD>2. Если текст есть, то нужно сделать diff этого текста и его новой версии и записать в БД новую версию и этот диф. По диф-у и тексту нужно иметь возможность получить предыдущую версию. В конечном итоге у нас должна храниться последняя версия целиком и набор дифов для всех изменений. На первых порах можно просто хранить все версии.

Зачем городить этот огород? Почему бы тупо не сохранять предыдущую версию целиком?

Здравствуйте, VladD2, Вы писали:

KV>>Не сочти за издевательство, но NT — это DAC

В чистом виде он не очень походит для веб-приложения, т.к. в этом случае (дискреционного доступа), владелец информации (тот, кто ее создал или получил во владение, если имел на это право) получает безграничный контроль над этой информацией. Но ACL'и, которые обсуждались на тимовском форуме — это как раз оттуда, да.

VD>Владельцев мы не рассматривали. В нашем случае достаточно чтобы права могли менять админы. Нам важен именно аналог ACL. То есть некоторая хрень которая позволит быстро понять доступны для некоторого пользователя некоторые данные или нет.

Вообще-то рассматривали. Список ролей был такой: Custom, Everyone, User, Owner, Self.

Здравствуйте, IT, Вы писали:

IT>А что насчёт Nemerle и FW 4.0? Не хотелось бы использовать старую версию фреймворка в таком проекте.

Да кто-то добрый портировал, но интеграция то по известным причинам пока что работать не будет.

Здравствуйте, IT, Вы писали:

VD>>2. Если текст есть, то нужно сделать diff этого текста и его новой версии и записать в БД новую версию и этот диф. По диф-у и тексту нужно иметь возможность получить предыдущую версию. В конечном итоге у нас должна храниться последняя версия целиком и набор дифов для всех изменений. На первых порах можно просто хранить все версии.

IT>Зачем городить этот огород? Почему бы тупо не сохранять предыдущую версию целиком?

Чтобы не хранить лишних данных. Если вдруг страницы начнут реально редактирвоать, то информация может не хило размножиться.

В прочем, я ниже писал, что в превом приближении можно просто дублировать.

В любом случае для вики-функциональности нужно уметь вделять изменения и сливать изменения от разных авторов. То есть, один фиг diff делать нужно уметь.

Здравствуйте, IT, Вы писали:

IT>Вообще-то рассматривали. Список ролей был такой: Custom, Everyone, User, Owner, Self.

Не помню такого.

Здравствуйте, VladD2, Вы писали:

IT>>Зачем городить этот огород? Почему бы тупо не сохранять предыдущую версию целиком?

VD>Чтобы не хранить лишних данных. Если вдруг страницы начнут реально редактирвоать, то информация может не хило размножиться.

Может для экономии места тогда лучше зиповать сообщения?

VD>В прочем, я ниже писал, что в превом приближении можно просто дублировать.
VD>В любом случае для вики-функциональности нужно уметь вделять изменения и сливать изменения от разных авторов. То есть, один фиг diff делать нужно уметь.

Если мы замахнёмся на всю возможную вики-функциональность, то не закончим этот проект никогда.

Здравствуйте, IT, Вы писали:

IT>Может для экономии места тогда лучше зиповать сообщения?

Одно другому не мешает. Только вот зиповать по одному сообщению — это не эффективно. Зиповать хорошо бы прямо темы (или каталоги).

Ну, и естественно делать это лучше только для старых тем, которые не поднимались довольно давно.

Мои эксперементы с офлайн-генератором показывают, что если брать только темы которые опднимались в течении года, то выходит всегда около 700 метров. В прочем, твое автозакрытие тем, видимо изменит эту статистику.

IT>Если мы замахнёмся на всю возможную вики-функциональность, то не закончим этот проект никогда.

Всю не все, а людям нужно видеть изменения внесенные автором. Думаю, что алгоритм diff-а можно надыбать в интернетах.

Ну, и конечно же можно отложить это дело до лучших времен. Но помнить о такой необходимости надо по любому.

Здравствуйте, VladD2, Вы писали:

IT>>Если мы замахнёмся на всю возможную вики-функциональность, то не закончим этот проект никогда.
VD>Всю не все, а людям нужно видеть изменения внесенные автором. Думаю, что алгоритм diff-а можно надыбать в интернетах.

Реализация диффа на немерле есть у меня

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, IT, Вы писали:

VD>>Владельцев мы не рассматривали. В нашем случае достаточно чтобы права могли менять админы. Нам важен именно аналог ACL. То есть некоторая хрень которая позволит быстро понять доступны для некоторого пользователя некоторые данные или нет.

IT>Вообще-то рассматривали. Список ролей был такой: Custom, Everyone, User, Owner, Self.

А протоколы рассмотрений где-нибудь остались? В обсуждениях на тимовском форуме я этого не нашел

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, VladD2, Вы писали:

VD>Атомарность обновления можно сделать путем запихивания запросов на редактирование в очередь. Все равно как такового параллельного редактирования по сути не будет.
Этого не достаточно.
Данная схема не защищает от выключения машина в момент записи в файл.

VD>Тут сразу нужно думать о бэкапе данных. Как ты представляешь себе бэкап кучи мелких БД?
А что из себя представляет БД SQLite? Правильно один фаил.

VD>Да и зачем тогда куча то?
Чтобы не мешали друг другу пра паралельном доступе.
Стандартный паттерн при разработке высоконагруженных систем.
Кстати по хорошему схему основной БД нужно продумывать с учетом возможности разбить ее на несколько кусков.

VD>А кому он нужен то? Нужны конечные версии страниц.
Так после обработки блоба конечная страница и получается.

VD>Вообще, идея с файлами мне нравится больше не смотря на проблему с ароматностью обновления. И именно в виду ее практичности. Скопировать каталог проще нежели кучу БД. При этом бэкап может иди в фоне и даже осуществляться средствами синхронизации (ОС или сторонними).
А тут без разници.
Ибо тебе в обоих случаях придется позаботиться о том чтобы процесс бекапа не подрался с процессом записи.

ЗЫ Я этими вещами занимался в яндексе так что знаю не по наслышке.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, WolfHound, Вы писали:

VD>>Атомарность обновления можно сделать путем запихивания запросов на редактирование в очередь. Все равно как такового параллельного редактирования по сути не будет.
WH>Этого не достаточно.
WH>Данная схема не защищает от выключения машина в момент записи в файл.

Вот эта штука спасает отцов русской демакратии. Доступна начиная с Win2008Server и Висты. Подробности здесь.

VD>>Тут сразу нужно думать о бэкапе данных. Как ты представляешь себе бэкап кучи мелких БД?
WH>А что из себя представляет БД SQLite? Правильно один фаил.

Дык и SQL-севренная БД — это один файл. Но бакапить их все же сложнее. Да и срезу не ясно зечем нам левые СУБД на сервере, если и так есть MS SQL Server.

Так что выбор только из MS SQL Server или файлами. Отдельная СУБД тоже не особо нужна. Достаточно хранить данные в отдельной таблице. Если что можно их средствами SQL-сервера вынести в отдельную файловую группу.

VD>>Да и зачем тогда куча то?
WH>Чтобы не мешали друг другу пра паралельном доступе.

SQL лучше решит эту проблему. Ну, а еще лучше файловая система. Параллельный доступ на чтение — это фигня. Запись у нас будет в основном на добавление. Редактирование будет очень редким явлением. Это нужно учитывать.

WH>Стандартный паттерн при разработке высоконагруженных систем.
WH>Кстати по хорошему схему основной БД нужно продумывать с учетом возможности разбить ее на несколько кусков.

Для этого у SQL-сервер есть свои механизмы. Тут скорее нужно учитывать специфику работы. Ведь в основном данные читаются, а не правятся. Сейчас БД фактически лежит в оперативке, что обеспечивает очень высокую скорость работы.

VD>>Вообще, идея с файлами мне нравится больше не смотря на проблему с ароматностью обновления. И именно в виду ее практичности. Скопировать каталог проще нежели кучу БД. При этом бэкап может иди в фоне и даже осуществляться средствами синхронизации (ОС или сторонними).
WH>А тут без разници.
WH>Ибо тебе в обоих случаях придется позаботиться о том чтобы процесс бекапа не подрался с процессом записи.

На то есть блокировки (и транзакции). Так что это не проблема. А вот, дополнительные вкусности, вроде возможности архивации старых файлов прямо средствами ОС очень даже радуют.

WH>ЗЫ Я этими вещами занимался в яндексе так что знаю не по наслышке.

Тут все не лаптем щи хлебают. Но думать нужно не только о производительности. Это многофакторная задча. Простота бэкапа тоже очень важна.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Реализация диффа на немерле есть у меня

Работает довольно шустро, но и есть что заоптимизировать. Поддерживаются двоичный и построчный-текстовый диффы, можно прикрутить любой другой формат, реализовав нужный интерфейс. Сейчас он гвоздями прибит к коду, в котором используется... Могу отцепить в отдельную сущность и куда-нибудь выложить.

Ну, что-то есть и у нас (на шарпе правда). Но то бинарный диф. Тут важно прикрутить его к структуре вики. Ведь там еще вормат есть. Его видимо надо как-то отдельно обрабатывать.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>А протоколы рассмотрений где-нибудь остались? В обсуждениях на тимовском форуме я этого не нашел

Только там и обсуждали. Что такое протоколы я даже представить себе не могу.

Здравствуйте, VladD2, Вы писали:

VD>Тут важно прикрутить его к структуре вики. Ведь там еще вормат есть. Его видимо надо как-то отдельно обрабатывать.

А что будем считать за единицу версионности? (символ, строка, абзац, токен в терминах грамматики языка разметки и т.п.)

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>А что будем считать за единицу версионности? (символ, строка, абзац, токен в терминах грамматики языка разметки и т.п.)

Хз. Тут надо думать.

Возможно сначала нудно сравнивать разметку, а уже потом внутри нее текст. Вообще, нужно смотреть на поведение других вик.

KV>>А что будем считать за единицу версионности? (символ, строка, абзац, токен в терминах грамматики языка разметки и т.п.)

VD>Возможно сначала нудно сравнивать разметку, а уже потом внутри нее текст. Вообще, нужно смотреть на поведение других вик.

Да лаааадно... МедиаВики отлично работает с построчными диффами на уровне статей. А она на пехапе написана.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Реализация диффа на немерле есть у меня

Здравствуйте, catbert, Вы писали:

VD>>Возможно сначала нудно сравнивать разметку, а уже потом внутри нее текст. Вообще, нужно смотреть на поведение других вик.

C>Да лаааадно... МедиаВики отлично работает с построчными диффами на уровне статей. А она на пехапе написана.

Что значит "с построчными"? Там ведь сравнивается текст, не текст с разметкой. Значит они сравнивают не просто текст.

Здравствуйте, VladD2, Вы писали:

VD>Что значит "с построчными"? Там ведь сравнивается текст, не текст с разметкой. Значит они сравнивают не просто текст.

А чему противоречат диффы текста с разметкой?

Здравствуйте, IT, Вы писали:

IT>Скорее мы пытались интуитивно использовать обе модели. С одной стороны нам нужно разделение прав доступа к ресурсам (видимо это MAC), с другой разделение прав доступа к определённым действиям (это роли). Обе модели реализуются по разному и практически не пересекаются. Если для ролей есть вполне приличная поддержка со стороны ASP.NET, то для управления доступом к ресурсам нужно придумывать свою схему и здесь важна в первую очередь производительность. А учитывая, что у нас почти 4 миллиона сообщений и около 100 тысяч пользователей в базе, то в лоб такая задача плохо решается.

Если использовать наследование, то не все так плохо. Т.е. в каждом сообщении появляется ссылка на acl предка. Т.е. размер базы увеличится на количество различных ACL плюс на размер ключа в ACL для каждого сообщения. Не так критично вобщем.

Главная загвоздка будет на выборках. Если их результат начнет зависеть от пользователя — все кеширования сразу пойдут лесом.

Но если ввести ограничения, например доступ на чтение открыт для всех (спец случаи как-то захардкодить) — сложные проверки останутся только при изменениях, а это уже вполне посильная нагрузка.

Здравствуйте, Ziaw, Вы писали:

Z>А чему противоречат диффы текста с разметкой?

А как ты их пользователю выводить собираешься? К тому же алгоритмы не будут в силах понять, что код форматирования относится к текущему тексту или идущему ниже. Будут накладки. Если сначала построить структуру документа, а потом сравнить внутри нее отдельный текст, то получится куда лучше.

В прочем, я вики никогда не делал.

Здравствуйте, VladD2, Вы писали:

Z>>А чему противоречат диффы текста с разметкой?

VD>А как ты их пользователю выводить собираешься? К тому же алгоритмы не будут в силах понять, что код форматирования относится к текущему тексту или идущему ниже. Будут накладки. Если сначала построить структуру документа, а потом сравнить внутри нее отдельный текст, то получится куда лучше.

С разметкой и выводить. К примеру вот так выглядит дифф в википедии.

Здравствуйте, Ziaw, Вы писали:

VD>>А как ты их пользователю выводить собираешься? К тому же алгоритмы не будут в силах понять, что код форматирования относится к текущему тексту или идущему ниже. Будут накладки. Если сначала построить структуру документа, а потом сравнить внутри нее отдельный текст, то получится куда лучше.

Z>С разметкой и выводить. К примеру вот так выглядит дифф в википедии.

Можно конечно и так. Так значительно проще реализовать. Хотя я бы предпочел сравнивать рендеренный результат, а не код.

Здравствуйте, Ziaw, Вы писали:

...

Если дифить код, то вообще проблем нет. Алгоритм найти не проблема.

Например, можно взять готовый вариант здесь.

Там бинарный диф. Но думаю, он без проблем должен работать с текстом. Плюс он доработан напильником для работы с большими файлами (более 2 гигов)

Здравствуйте, Ziaw, Вы писали:

IT>>Скорее мы пытались интуитивно использовать обе модели. С одной стороны нам нужно разделение прав доступа к ресурсам (видимо это MAC), с другой разделение прав доступа к определённым действиям (это роли). Обе модели реализуются по разному и практически не пересекаются. Если для ролей есть вполне приличная поддержка со стороны ASP.NET, то для управления доступом к ресурсам нужно придумывать свою схему и здесь важна в первую очередь производительность. А учитывая, что у нас почти 4 миллиона сообщений и около 100 тысяч пользователей в базе, то в лоб такая задача плохо решается.

Z>Если использовать наследование, то не все так плохо. Т.е. в каждом сообщении появляется ссылка на acl предка. Т.е. размер базы увеличится на количество различных ACL плюс на размер ключа в ACL для каждого сообщения. Не так критично вобщем.

Можно подумать насчёт чего-то вроде Access Control ID и снабжать им ресурсы, а уже его вязать с ACL.

Z>Главная загвоздка будет на выборках. Если их результат начнет зависеть от пользователя — все кеширования сразу пойдут лесом.
Z>Но если ввести ограничения, например доступ на чтение открыт для всех (спец случаи как-то захардкодить) — сложные проверки останутся только при изменениях, а это уже вполне посильная нагрузка.

Именно. У нас есть две большие группы, которые покрывают 99% запросов сейчас, это анонимы и обычные юзеры. Для этих групп должны формироваться отдельные фильтры в запросах.

Здравствуйте, IT, Вы писали:

IT>Можно подумать насчёт чего-то вроде Access Control ID и снабжать им ресурсы, а уже его вязать с ACL.

Да мы вроде бы об этом уже думали и пришли к выводу что так и нужно делать. Точнее ACL должен быть таблицей с этим самым ID. А ресурсы должны хранить этот ID.

Z>>Главная загвоздка будет на выборках. Если их результат начнет зависеть от пользователя — все кеширования сразу пойдут лесом.
Z>>Но если ввести ограничения, например доступ на чтение открыт для всех (спец случаи как-то захардкодить) — сложные проверки останутся только при изменениях, а это уже вполне посильная нагрузка.

IT>Именно. У нас есть две большие группы, которые покрывают 99% запросов сейчас, это анонимы и обычные юзеры. Для этих групп должны формироваться отдельные фильтры в запросах.

А зачем отдельные? Если принять схему с ACL и его ID, то все получится автоматом. Просто у юзеров и анонимов будет ровно по одному ACL-у в списке.

Еще вопрос в забаненных юзерах. Или в отрицательных ACL-ах (если прнять такую схему и реализовать забанных через нее).

Здравствуйте, VladD2, Вы писали:

VD>А зачем отдельные? Если принять схему с ACL и его ID, то все получится автоматом. Просто у юзеров и анонимов будет ровно по одному ACL-у в списке.

Точно. А раз так, то из фильтра можно убрать таблицу с ролями, таблицу ACE (Role/ACL), а для анонимов возможно и саму ACL, тогда для анонимов фильтрация сведётся к простому условию в WHERE целевых таблиц. Для юзеров тоже можно дооптимизироваться до WHERE AclID IN (..., ...)

VD>Еще вопрос в забаненных юзерах. Или в отрицательных ACL-ах (если прнять такую схему и реализовать забанных через нее).

Бан большее имеет отношения к роли, чем к доступу к ресурсам. Я бы сюда это не мешал.

Здравствуйте, IT, Вы писали:

IT>Точно. А раз так, то из фильтра можно убрать таблицу с ролями, таблицу ACE (Role/ACL), а для анонимов возможно и саму ACL, тогда для анонимов фильтрация сведётся к простому условию в WHERE целевых таблиц. Для юзеров тоже можно дооптимизироваться до WHERE AclID IN (..., ...)

Думаю, что для всех можно "WHERE AclID IN (...)" использовать. SQL-сервер не идиоты писали. Если в in будет одно или два значения, то его заоптимизируют. На крайняк добавим трансформацию "WHERE AclID IN (X, Y)" в "WHERE AclID = X or AclID = Y". Причем прямо в БЛТулкике

.

VD>>Еще вопрос в забаненных юзерах. Или в отрицательных ACL-ах (если прнять такую схему и реализовать забанных через нее).

IT>Бан большее имеет отношения к роли, чем к доступу к ресурсам. Я бы сюда это не мешал.

А я бы мешал. В прочем, это уже детали. Я только не понял нафиг нам тут какие-то роли? В прочем группы, роли... лишь бы в печь не ставили...

Здравствуйте, IT, Вы писали:

IT>Скорее мы пытались интуитивно использовать обе модели. С одной стороны нам нужно разделение прав доступа к ресурсам (видимо это MAC), с другой разделение прав доступа к определённым действиям (это роли).

А MAC в чистом виде практически и не используется (см. ниже).

IT>Обе модели реализуются по разному и практически не пересекаются. Если для ролей есть вполне приличная поддержка со стороны ASP.NET, то для управления доступом к ресурсам нужно придумывать свою схему и здесь важна в первую очередь производительность. А учитывая, что у нас почти 4 миллиона сообщений и около 100 тысяч пользователей в базе, то в лоб такая задача плохо решается.

Давай я пофантазирую на тему того, каким мог бы быть контроль доступа на RSDN (на базе гибрида MAC и ролевого доступа), а вы с Владом решите, почему он не подходит?

В первую очередь, определимся с тем, что является субъектами и объектами доступа. Субъектами будут являться пользовательские сессии, а отнюдь не пользователи, как здесь раньше обсуждалось. Тому есть несколько причин, чтобы не растекаться мыслью я их опущу и, если надо распишу позже. С объектами же все несколько сложнее. Дело в том, что обеспечить однородность объектов доступа в случае данного сайта крайне тяжело. Во-первых, это будут те самые "ноды", о которых писал Влад на тимовском форуме и которые тут я назвал "сообщениями". Во-вторых, это будут разделы сайта не относящиеся к нодам, такие как админ-интерфейс (то, что не удасться интегрировать в основное представление страниц сайта, например — список забаненных), профиль пользователя и т.п. В приципе, ничто не мешает сделать это все "нодами" и это было бы идеально с т.з. безопасности, но и являлось бы весьма серьезным решением с т.з. архитектуры всего сайта, поэтому тут я хз, надо обсуждать. Далее, я буду исходить из того, что сие серьезное решение места не имеет и у нас объекты доступа разнородны.

В MAC принятие решения о предоставлении доступа или отказе принимается следующим образом: каждый субъект и объект доступа снабжается т.н. меткой безопасности состоящей из двух частей: уровня конфиденциальности ("конфиденциально", "публично доступно" и т.п.) и категорий ("проект А", "проект Б" и т.п.). При принятии решения о доступе к чему либо, метки субъекта и объекта сравниваются следующим образом: уровень конфиденциальности субъекта (его уровень допуска) должен быть не ниже чем соответствующий уровень объекта, а список категорий у субъекта должен ключать в себя весь список категорий объекта. Из этого следует основной недостаток чистого MAC'а — он определяет только возможность доступа (и позволяет это делать очень дешево с т.з. производительности), но не конкретизирует перечень действий, которые может совершить субъект с объектом.

Поэтому, мы скомбинируем MAC с одной из распространенных моделей, решающих данную проблему. Таких моделей две: DAC и RBAC. Первая — дискреционная модель, подразумевает такое понятие как "владелец объекта доступа", предоставляя ему ничем не ограниченные права в т.ч. и на определение прав доступа к объекту. В DAC субъекты снабжаются листами доступа (ACL) в которых указано какие именно субъекты, могут совершать с данным объектом те или иные действия. Это именно то, что реализовано в NT и что вы здесь обсуждали. Проблема в том, что в ASP.NET уже реализована (как справедливо заметил IT, весьма прилично) модель доступа, отличная от DAC. Это — RBAC, ролевая модель, в которой уровень доступа определяется членством субъекта в какой-либо группе (т.е. принадлежностью к роли), соответственно у объектов понятие ACL отсутствует в принципе, их заменяет либо централизованный список разрешений для каждой из групп, либо данный список хардкодится прямо в систему, что является вариантом малоприемлемым, но тем не менее. Посему, нужно либо вообще отказываться от уже реализованного в ASP.NET и писать свой провайдер авторизации (я пробовал — это ни с чем не сравнимый гемморой), либо сэмулировать DAC на RBAC'е, что навскидку, является куда менее гемморным занятием.

Таким образом, мы будем использовать MAC как дешевый способ определить может ли вообще субъект осуществлять тот или иной доступ, и, если может, то будем дополнительно использовать DAC over RBAC для определения, какой именно.

Сначала MAC: все метки безопасности, которыми мы снабдим и субъектов и объектов будут содержать один из уровней конфиденциальности:

0 = Аноним
1 = Зарегистрированный пользователь
2 = Тимер
3 = Модератор
4 = Администратор

и одну или несколько категорий классификации:

Форум
Список тем форума
Тема форума
Сообщение форума
Статья вики
Комментарий к статье вики

и т.п.

Т.о. если аноним (имеющий уровень конфиденциальности "0") запросит тему из тимовского форума (имеющую уровень конфиденциальности "2"), то получит отлуп после простого сравнения двух целых чисел. Другой пример: аноним, даже прошедший проверку уровня конфиденциальности, но не имеющий в списке категорий элементов "Статья вики" и "Комментарий...", получит отлуп, запросив статью из вики, после сравнения списка айдишников категорий его метки и списка айдишников категорий метки этой статьи.

Каким боком мы сюда притянем RBAC? Очень просто — наши уровни конфиденциальности из MAC будут одновременно ролями в терминах RBAC. А категории, айдишники которых содержатся в метках безопасности, будут включать в себя не только название, но и ACL (либо его айдишник), в котором будет перечислено какая из групп какие действия может совершить с объектом данной категории

Остались нерешенными два вопроса: наследование прав объектами и роль "владелец" объекта. Наследование может быть реализовано как копированием метки доступа родителя, так и хранением айдишника метки родителя. И в том и другом случае наследоваться они должны по следующим правилам:

1. Дочерний уровень конфиденциальности всегда замещается родительским
2. Списки категорий родителя и дочки (а следовательно и их ACL'и) объединяются

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

"Владелец объекта" реализуется, например, следующим образом: вводим новую одноименную роль (а следовательно и уровень конфиденциальности со значением 5, т.е. самым высоким), не присваиваем ее никому из субъектов и объектов, но заводим таблицу, хранящую список владельцев каждого из объектов. Перед тем, как проверять возможность доступа в MAC'е, делаем выборку из этой таблицы и если текущий субъект является владельцем запрошенного объекта, то меняем в обоих метках (не в базе, разумеется) уровень конфидециальности на 5-ый и далее работаем так, как было описано выше. Конечно, для каждой из категорий классификации дожен быть заранее прописан ACL для роли "Владелец".

Ну вот, как-то так

P.S: Бонусная мысль, спорная, но IMHO интересная. Львиной доли проверок можно избежать, если вынести их в отдельный слой (Access Control Layer) в виде эдакого generic-слоя и конкретизировав его в момент создания сессии меткой безопасности текущего субъекта, скомпилировать в отдельную сборку, через которую и будет осуществляться доступ ко всем ресурсам сайта в рамках этой сессии. Если это интересно, могу раскрыть мысль шире, но позже, ибо уже валюсь с ног

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, VladD2, Вы писали:

VD>Так что выбор только из MS SQL Server или файлами. Отдельная СУБД тоже не особо нужна. Достаточно хранить данные в отдельной таблице. Если что можно их средствами SQL-сервера вынести в отдельную файловую группу.

Если SQL Server 2008 и выше, то выбор делать не нужно, есть Filestream.

Здравствуйте, Ziaw, Вы писали:

Z>Если использовать наследование, то не все так плохо. Т.е. в каждом сообщении появляется ссылка на acl предка. Т.е. размер базы увеличится на количество различных ACL плюс на размер ключа в ACL для каждого сообщения. Не так критично вобщем.
Можно еще озаботиться убиранием дублированных ACL, для этого каждому ACL ставится в однозначное соответствие строка и при попытке добавить новый ACL в базу ищется запись с таким "ключом".
Если цеплять права не на отдельных пользователей, а на группы, то различных ACL наберется десятка два.

Z>Главная загвоздка будет на выборках. Если их результат начнет зависеть от пользователя — все кеширования сразу пойдут лесом.
Неправда, есть private кеширование, когда документ кешируется только на клиентской стороне, главное last modified и etag выставлять.
А на сервере документы кешируются точно также, только дополнительная проверка доступа происходит при обращении.

Здравствуйте, gandjustas, Вы писали:

Z>>Если использовать наследование, то не все так плохо. Т.е. в каждом сообщении появляется ссылка на acl предка. Т.е. размер базы увеличится на количество различных ACL плюс на размер ключа в ACL для каждого сообщения. Не так критично вобщем.
G>Можно еще озаботиться убиранием дублированных ACL, для этого каждому ACL ставится в однозначное соответствие строка и при попытке добавить новый ACL в базу ищется запись с таким "ключом".
G>Если цеплять права не на отдельных пользователей, а на группы, то различных ACL наберется десятка два.

Да, тогда перед запросом из acl будут выбраны те, которые разрешают доступ (выборку можно свести к очень быстрой операции) и сам фильтр сведется к acl_id in (). Так как большинство запросов на чтение идут с одним набором — есть хорошая вероятность, что процентов 90% запросов лягут в кеш сервера.

Z>>Главная загвоздка будет на выборках. Если их результат начнет зависеть от пользователя — все кеширования сразу пойдут лесом.
G>Неправда, есть private кеширование, когда документ кешируется только на клиентской стороне, главное last modified и etag выставлять.
G>А на сервере документы кешируются точно также, только дополнительная проверка доступа происходит при обращении.

Кеширование на клиентской стороне тут конечно поможет, особенно на конкретные страницы. Проблема была не перегрузить сервер сложными запросами при показе списков страниц (то, что в правом верхнем фрейме), у этих списков last modified вычисляется ничуть не дешевле вытаскивания самого списка. Впрочем отвечать not modified после вытаскивания тоже полезно. Как для экономии исходящего канала, так и для большей отзывчивости интерфейса.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, gandjustas, Вы писали:

Z>>>Если использовать наследование, то не все так плохо. Т.е. в каждом сообщении появляется ссылка на acl предка. Т.е. размер базы увеличится на количество различных ACL плюс на размер ключа в ACL для каждого сообщения. Не так критично вобщем.
G>>Можно еще озаботиться убиранием дублированных ACL, для этого каждому ACL ставится в однозначное соответствие строка и при попытке добавить новый ACL в базу ищется запись с таким "ключом".
G>>Если цеплять права не на отдельных пользователей, а на группы, то различных ACL наберется десятка два.

Z>Да, тогда перед запросом из acl будут выбраны те, которые разрешают доступ (выборку можно свести к очень быстрой операции) и сам фильтр сведется к acl_id in ()

Можно и не делать отдельный запрос на выборку acl, а просто проджоинить два запроса и вытащить только данные.

Z>>>Главная загвоздка будет на выборках. Если их результат начнет зависеть от пользователя — все кеширования сразу пойдут лесом.
G>>Неправда, есть private кеширование, когда документ кешируется только на клиентской стороне, главное last modified и etag выставлять.
G>>А на сервере документы кешируются точно также, только дополнительная проверка доступа происходит при обращении.

Z>Кеширование на клиентской стороне тут конечно поможет, особенно на конкретные страницы. Проблема была не перегрузить сервер сложными запросами при показе списков страниц (то, что в правом верхнем фрейме), у этих списков last modified вычисляется ничуть не дешевле вытаскивания самого списка.
Если смотреть на текущий форум, то last modified вытаскивается через последнее сообщение (которое на главной странице справа) и для этого не надо все темы подтягивать.

Z>Впрочем отвечать not modified после вытаскивания тоже полезно. Как для экономии исходящего канала, так и для большей отзывчивости интерфейса.
А кто мешает закешировать last modified?

Здравствуйте, gandjustas, Вы писали:

G>Можно и не делать отдельный запрос на выборку acl, а просто проджоинить два запроса и вытащить только данные.

В том то и оптимизация, что acl движком бд проверяется не очень хорошо, а потом еще и джойн. Совсем не факт, что даже этот джойн будет так же эффективен как in (который при некоторых выкрутасах с оптимизацией можно для обычных юзеров свести к AclId < @param).

Фишка как раз в том, чтобы моментально получать разрешающие acl. Исходный список закешировать проще простого — одна небольшая таблица, изменения редки. Потом применить их к текущему юзеру (сессии). Это тоже довольно простой in process memory алгоритм. А потом уже добавлять очень простой фильтр к запросу для БД.

Здравствуйте, Воронков Василий, Вы писали:

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

Блог на nemerle.org читал? Там было что то и по дизайну и о причинах. Блог сейчас недоступен, но копию можно найти в архиве — http://web.archive.org/web/20080426004132/http://nemerle.org/blog/

Здравствуйте, VladD2, Вы писали:

VD>В последнее время народ стал постоянно поднимать вопрос блогов, вики и других новомодных новоротов для немерла.
VD>Выскажу свое мнение.

VD>Главное что мне категорически не нравится — это если информация по немерлу начнет разъезжаться по разным сакйтам.
Видимо это по поводу моих отсылок к друпалу. Я кстати не предлагал переехать на другие сайты. Друпал можно поставить на свой сайт и держать на нем все блоги/вики/треккеры — все-в-одном, до тех пор, пока не будет допилен rsdn. Друпал кстати хорошо живет под 6-7 iis-ом, тем более с установленным fastcgi. Доки по установке и настройке есть на сайте iis.net, а это вроде как официальный сайт поддержки iis-а. Ну да бог с ним, с друпалом, идея написать сайт Немерле на nrails мне нравится больше.

VD>Мне кажется багтреккер и вики нужно перенести на гугль-код.
Багтреккер точно стоит перенести (тем более в гугле он интегрирован с svn-ом), а вот насчет вики я бы подумал. Я вообще разочаровался в идее использовать вику в качестве движка для базы знаний. Вика плохо структурирована, по сути это плохо управляемая куча документов, связанных друг с другом перекрестными ссылками. Потерять документ в вике — плевое дело, стоит только удалить (или отредактировать) страницу, на него ссылающуюся. Человек, не знакомый со структурой конкретной вики, легко в ней запутается.

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

Вику можно использовать для часто изменяющихся рабочих документов (типа роадмапов, таймлайнов, руководства по сборке билда, по настройке окружения), а вот статьи, референсы по языку, учебные курсы и т.д. лучше хранить в более строгой структуре. Ну а блог — "для путевых заметок", где участники прокта делились бы своими находками, обсуждали решения, планы и фичи. Вобщем для того же, для чего Камил сотоварищи использовали старый блог на nemrele.org — http://web.archive.org/web/20080426004132/http://nemerle.org/blog/

VD>Что касается блогов, тут вопрос особый, так как я не вижу того кто будет их писать.
Записи в блоге не обязательно долдны быть объемными и обстоятельными. Например по поводу твоей новой фичи с автокомплитом в $ строках и linq для начала достаточно было бы абзаца текста и скриншота. Еще можно подводить в блоге итоги здешних обсуждений по дизайну, например обсуждения области видимости анонимных классов (http://rsdn.ru/forum/nemerle/3824368.1.aspx). Я бы еще мог описывать релиз ноутсы и прогресс по реализации поддержки web проектов.

VD>

Собственно идея...

VD>Вопрос в том кто есть ли желающие взяться за такую работу?
VD>Естественно, что средством реализации будет немерл и NRails.

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

Здравствуйте, kochetkov.vladimir, Вы писали:

...

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

В общем случае, задача предоставления доступа отдельному субъекту к отдельному объекту решается в такой модели через создание новой категории классификации, уникальной только для этого объекта и ее добавлению в метки безопасности и субъекта и объекта. Это может показаться громоздким, но дает два преимущества:

1. В любой момент времени, имея метку текущей сессии, мы имеем всю необходимую информацию для того, чтобы одним запросом в бд выгрести только то, к чему имеет доступ пользователь сессии.
2. При каждой "точечной" раздаче прав, категории классификации будут плодиться, зато ACLи — не обязательно, т.к. мы можем использовать один ACL для всех авторов статей. И если (ну вдруг) мы захотим дать авторам статей дополнительные права, достаточно будет изменить только один ACL.

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

Набросать что-нибудь типа ER-диаграммы, отражающей эту модель, чтобы было нагляднее?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>2. При каждой "точечной" раздаче прав, категории классификации будут плодиться, зато ACLи — не обязательно, т.к. мы можем использовать один ACL для всех авторов статей. И если (ну вдруг) мы захотим дать авторам статей дополнительные права, достаточно будет изменить только один ACL.

Всем авторам права давать не надо. Ведь не надо чтобы авторы читали недописанные статьи друг друга. Надо давать права автору только не те темы в которых обсуждаются его статьи.

KV>Правда мне кажется более логичным, конкретно в случае с доступом авторов статей в закрытое обсуждение, просто создавать это обсуждение от их имени. В этом случае они будут владельцами этого объекта и получат права в ветку автоматом, вообще без каких-либо телодвижений.

Автор не должен быть владельцем этих тем. Он не должен иметь какие-то дополнительные права кроме возможности читать тему (вместе с ответами).

KV>Набросать что-нибудь типа ER-диаграммы, отражающей эту модель, чтобы было нагляднее?

Да, давай.

ЗЫ

Мы видели это несколько проще (хотя возможно я тебе просто не до понял). Мы видели схему очень простой. Есть много-много ACL-ей, каждый из которых идентифицируется через свое ID. ACL — это просто список тех субъектов и/или их групп которым разрешен доступ к объекту защиты. При создании сессии (или при изменении ACL-ей в которые он входит) пользователя он считывает список id ACL-ей в которые он входит. Далее вопрос разрешения доступа (на чтение) решается или путем SELECT ... WHERE ACL_ID id (список_ACL_ID_закешированный_ранее), или путем одного джоина с таблицей ACL-ей.

Учитывая, что у нас будет не много хитро защищенных объектов это должно прокатить. Плодиться при этом будут группы и ACL-и. Но каждый юзер должен иметь вменяемый набор ACL_ID, что должно привести к высокой производительности.

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

От:	VladD2	www.nemerle.org
Дата:	18.05.10 16:22
Оценка:	81 (6) +1

	От:	catbert
	Дата:	18.05.10 16:44
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	18.05.10 17:04
Оценка:

	От:	Ziaw
	Дата:	18.05.10 17:06
	Оценка:

От:	Real 3L0	http://prikhodko.blogspot.com
Дата:	20.05.10 12:06
Оценка:

От:	FDSC	consp11.github.io блог
Дата:	20.05.10 12:42
Оценка:

	От:	Arsen.Shnurkov
	Дата:	21.05.10 01:44
	Оценка:	+1

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	21.05.10 16:03
Оценка:

	От:	Воронков Василий
	Дата:	21.05.10 18:57
	Оценка:

От:	IT	linq2db.com
Дата:	27.05.10 17:41
Оценка:	+1

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	30.05.10 05:35
Оценка:	+1

От:	seregaa	http://blogtani.ru
Дата:	31.05.10 23:05
Оценка: