capability myths (англ.)

[avva]

Вот хорошая статья какая:

Capability Myths Demolished

(для программистов в основном)

Мне неплохо мозги прочистила и некоторый порядок навела, а то я не очень понимал, что там за извечная вражда между ACLs и capabilities. Теперь лучше понимаю. Рекомендую.

Comments

[dimrub.livejournal.com]

После неудачного опыта IMAP standartization, меня от слова capabilities начинает бить колотун. Марк Криспин - не просто было с ним общаться.

[avva.livejournal.com]

Как написала одна нет.легенда в одном частном письме недавно (я был одним из его получателей): "Ugh, does anyone actually use IMAP?"

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

[dimrub.livejournal.com]

Тут Вы не правы. Верно, что многие ISPs еще пользуются POP3, и что RPC over HTTP новой версии оутлука тоже станет популярным, куда он денется (не говоря о web based e-mail), но IMAP широко используется в качестве back end protocol во всевозможных мобильных системах messaging.

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

[avva.livejournal.com]

Это точно ;) я не совсем всерьёз, на самом деле.

А переписка возникла по поводу идеи построить IMAP-интерфейс к ЖЖ. Но пока эта идея тормозит, и не факт, что будет воплощена.

[dimrub.livejournal.com]

Не очень понятно, чем этот интерфейс будет хорош. Вот сделать smtp2lj гейт - это да. Это сильно облегчило бы жизнь road warriors. Я знаю, что есть неофициальные гейты, но что-то не хочеца дяде пароль давать.

Кстати, apropos nothing, так сказать: эйсиели эйсиелями, а меня очень удивляет неоправданная мультифункциональность понятия "френд". Говоря нормальным языком, не факт, что множество людей, которых я хочу читать, и множество людей, которым я хочу предоставить доступ к личным записям, совпадают и, в крайнем случае, даже пересекаются.

К тому же, само слово friend - misleading.

[nine_k]

'Friend' безусловно misleading.

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

[dimrub.livejournal.com]

Группы не решают проблему, если множество тех, кого я хочу читать, не является подмножеством тех, кому я хочу давать читать меня. Кроме того, группы не удобны: в них нельзя перейти одним нажатием через side bar, не изменив вида своего журнала (а это довольно муторно для рядового юзверя).

[nine_k]

Нет проблемы подмножеств. Пусть группа A -- те, кого я читаю (в пределе -- 'default view'), а группа B -- те, кому я даю доступ. Эти группы *совершенно* независимы друг от друга, хотя обе являются подмножествами списка friends (т. е. списка тех, с кем хоть как-то приходится иметь дело в явной форме).

Жаль, что групп нет на sidebar, факт, это могло бы быть полезной опцией для тех, кому они нужны. Но дописать к ...моёимя/friends имя группы (...моёимя/friends/группа) не так уж трудно для продвинутого пользователя, которому вся эта бодяга с группами вообще, вероятно, и может только понадобиться.

[dimrub.livejournal.com]

Пусть группа A -- те, кого я читаю (в пределе -- 'default view'), а группа B -- те, кому я даю доступ.

Но тогда доступ ко всем постам должен быть custom, с группой B, правильно я понимаю? Тоже не удобно.

[nine_k]

Да, правильно. Да, неудобно. Но да, возможно :-)

[avnik.livejournal.com]

Лучше бы доделали полноценный XML интерфейс, потому как было бы удобнее читать журнал спец клиентом, а не браузером.
(полноценный - чтобы можно было не только свой журнал в xml/rss выкачать - но и френдленту, и talk.*bml.)
Или не xml, а хотя бы xhtml со стилем типа lynx (но с сохранением юзерских приаттаченых картинок и юзерпиков) - пригодный для автоматического разбора.

[dimrub.livejournal.com]

Кстати, начал читать эту статью, спасибо за ссылку. Для себя я это определил, как описание различий в security models JVM и J2EE. Это очень странный, я бы даже сказал темный момент в эволюции джавы. Такое впечатление, что в Сане идут какие-то разборки между тупо- и остроконечниками, и никак не определят, что лучше, а народ страдает. То ли дело дот нет - единая security model, без всей этой шизофрении.

Шапиро и EROS

[gdy.livejournal.com]

В статье под именем Шапиро ссылка битая, правильно будет http://www.eros-os.com/. А внутри есть Essays on Capabilities and Security (http://www.eros-os.com/essays/00Essays.html)

Re: Шапиро и EROS

[avva.livejournal.com]

Спасибо!

[(Anonymous)]

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

что до capabilities (а я как-то участвовал в таком проекте) то
1. либо они представимы как битовая строка и тогда подделываемы, передаваемы неограниченно, и т.п.
2. либо очень грубая гранулярность доступа, сушественно хуже ACL,
3. либо любая система будет как черепаха или просто сдохнет от поддержки и отслеживания внутренних capabilities.