proNovell

ИМХО:

1. Принимать или НЕ принимать - личное и персональное дело юзера. И админу туда лезть в общем в принципе незачем. Посему только игнор-лист (вариант обратный - permit-list - плох, потому как все одно юзеру сперва придется нескольких или всех в него внести, а потом по мере доставания выносить оттуда)... кстати, вопрос возникает с тем где этот лист хранить (на станции - отпадает, на сервере? в дереве?)...

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

1. Принимать или НЕ принимать - личное и персональное дело юзера. И админу туда лезть в общем в принципе незачем. Посему только игнор-лист (вариант обратный - permit-list - плох, потому как все одно юзеру сперва придется нескольких или всех в него внести, а потом по мере доставания выносить оттуда)... кстати, вопрос возникает с тем где этот лист хранить (на станции - отпадает, на сервере? в дереве?)...

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

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

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

Коллеги, а можно мне тоже встрять?
Предлагается АНТИ-ХАМ АВТОМАТИЧЕСКИЙ (работать должен наподобии блокировки доступа к Дереву при исчерпании числа разрешенных попыток регистрации).
Действует примерно так: пользователь-цель, заваленный пустобрёхом, сам отключает прием сообщений от надоедающих соседей. При эотм сообщения не выводятся, но посылается служебное уведомления на станцию-источник "ваше сообщ. отвергнуто". А программа на источнике считает эти ответы и сравнивает с пороговым значением - например 10 отвергнутых сообщений в минуту или более 3х отвергнутых одной станцией-целью(условно; может меняться; см. ниже). И если порог превышен - отключат посылку сообщений минут на 5-10 с уведомлением шалунишки, чтоб впредь не хамил.
Не знаю , насколько это трудоёмко в реализации, но должно воспитывать. А админ может (должен??) централизованно раздавать квоту на порог срабатывания. (посредством служебных сообщений).
Вот.

Влад А. Сокол aka Akina писал(а):кстати, вопрос возникает с тем где этот лист хранить (на станции - отпадает, на сервере? в дереве?)...

И вправду нужно думать где хранить игнор лист.... ТОЛЬКО не в иниках....

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

2. Либо в NDS... Но тут вы не учитываете один факт... а если в дереве скажем 1000 польз-й и каждый из них засунет по 500 узеров в игнор лист... Это какие же тогда данные будут бегать по сети и лежать в NDS'е...???

Andrey Podoinikov писал(а):

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

Не представляю как это сделать

У меня есть вариант как это сделать...
На основе того же "листа"... Есть лист с юзверями кот. разрешено видеть пользователя в невидимом режиме... При запуске (или при переходе в режим невидимости) NWSend проверяет этот список... проверяет кто есть в сети... и делает какой-нибудь широковещательный ПИП (в этом запросе указывается какие юзверя могут меня видеть), другие NWSend'ы в сети этот запрос принимают и на основе его данных обновляют свой лист активных юзеров...

Сложно конечно НО.... можно... можно придумать и другие варианты...

У меня есть вариант как это сделать...
На основе того же "листа"... Есть лист с юзверями кот. разрешено видеть пользователя в невидимом режиме... При запуске (или при переходе в режим невидимости) NWSend проверяет этот список... проверяет кто есть в сети... и делает какой-нибудь широковещательный ПИП (в этом запросе указывается какие юзверя могут меня видеть), другие NWSend'ы в сети этот запрос принимают и на основе его данных обновляют свой лист активных юзеров...

Сложно конечно НО.... можно... можно придумать и другие варианты...

А если игнорируемый пипл загрузился позже? Он ведь не получит этот пип. А слать пипы через интервал времени... Эээ... Пожалейте лампады на свичах!

Мне выход видится только один. Андрей! Идея написать NLM-ку для запуска на сервере еще жива? Давно это было. Речь тогда шла об офф-лайн мессаджах. Она бы могла нести и эту нагрузку. Кто ей мешает держать свою БД на серванте? Не в NDS, а отдельно.

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

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

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

АНТИ-ХАМ АВТОМАТИЧЕСКИЙ - ИМХО очень сложно и, в общем то, делает то же, что я предлагаю, только несколько "через Пекин" ))) - насколько я понимаю в программировании. Потом - у Андрея, по моим данным, в настоящее время несколько иные устремления ))) - так что просить его сделать что-то уж очень сложное - как-то совестно.

Лучше всех, как мне кажется, отразил мое мнение Влад А. Сокол aka Akina Прямо в точку. Есть функциональность и одного, и другого рода (криво получилось - надеюсь, меня все поймут)

По поводу "где хранить" - заморачиваться с реестром - смысла нет. Потому как доступ к реестру контролирует не каждый админ. Следовательно, хам с головой (и такие есть, поверьте) смогет эту блокировку снять. Гораздо безопаснее и надежнее держать ACL в свойствах объекта Пользователь НДС - складывать туда ID всех придурков и все. На мой взгляд - операция достаточно безобидная и безопасная (если я что-то понимаю в программировании БД). Правда, необходимо дать разрешение юзверю менять это свойство самостоятельно - ИМХО, админу просто для нвсенда надо дать один раз права и все. И работать это будет, учитывая скорость работы НДС, побыстрее прочих БД ))) Что же касается

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

не совсем согласен. Админу достаточно объяснить в ридми, что производится и с какой целью ))) Если бы все боялись изменений в схеме - о продуктах типа ЗЕН илиГрупВайз говорить было бы просто смешно ))) И потом - расширение схемы - абсолютно безопасная (с точки зрения безопасности доступа) операция - всего лишь добавляются новые поля к базе! Дать право туда писать или нет и если дать - то кому - дело админа. Он абсолютно запросто может все это контролировать!

Для Андрея Подойникова:
Андрей можно вас попросить в командной строке добавить параметр группа c:\nwsend.exe /s:server_name /g:group_name.context1.context2 /m:Текст сообщения

Андрей можно вас попросить в командной строке добавить параметр группа c:\nwsend.exe /s:server_name /g:group_name.context1.context2 /m:Текст сообщения

Это уже есть в версии NWSend 4.0 - см. хелп файл

Они нужны только на коннекты. А NLMок куча юзает бтривовские базы, сервер без него не работает, там вся конфигурация IP, Nias, аудит .....
Если обращаться к NLM на сервере, а уж она будет читать базу, то никаких проблем не возникнет. Типичная трехзвенка.