> Так гугол в помощь - наверняка кто-то уже озадачился и написал. Если
> нет - могу написать для вас, за цену билета на самолет ;)Вы там вообще в своем уме? Нафига я буду возиться с тем что вообще должно работать по дефолту, т.к. обыденный и повсеместный сценарий? И тем более - за что платить вам? Это ж не кастомдев, это - СТАНДАРТНАЯ хотелка, типичная для *легиона* юзерей. Прикиньте?
Там вон как видим есть желающие делать это и не требуя с меня оплаты (потому что им самим надо, по тем или иным причинам). А раз так - посчитаем что я в этом заинтересован (и даже попытаюсь подыграть заинтересованным чем умею).
> Переложенное мной решение - скрипт решающий четко поставленную задачу для конкретных
> классов устройств. Его можно быстро написать и отладить. При появлении нового
> класса устройств - легко добавить.
Единственная проблема: постановка задачи отморожена на всю голову и являет собой образец квадратно-гнездового мышления имени мсдоса. Если я сажусь в самолет, последнее о чем я хочу думать в этот момент - какие же там в этом девайсе классы беспроводных устройств?! Есть четко поставленная задача: ВСЕ РАДИО ДОЛЖНЫ ЗАТКНУТЬСЯ. Вот это - нормальная человеческая постановка задачи. С понятной мотивацией (чтобы не было шанса создать помехи навигационному оборудованию) и логичной реализацией через нечто типа системной шины.
А то что вы предлагаете - эталонный образец ДОСявого однозадачного однопроцессного мышления: перехватить контроль над девайсом единолично из 1 приблуды и вообще никак не согласовывать с другим софтом использование этого девайса. Арбитраж? Использование более чем 1 программой? Не, не слышали! Вот поэтому и мамонты, собственно...
> То, что предлагаете вы - это попытка создать все на все случае жизни,
Не совсем так. Это попытка создать интерфейс который справился бы с рядом типовых задач без убер-костылирования. Позволив решать задачи логично и естественно. Удобно и для програмеров и логично для юзеров. Нет, трахать свой мозг садясь в самолет какие там в ноуте или где там еще классы девайсов - нифига не удобно и не логично, уважаемый мамонт.
> говоря уж об overkill/overhead/overengineering.
Ну конечно, ваши кастомные ни с чем не совместимые и ни с чем нормально не взаимодействующие скриптокостыли - это не оверкилл, не оверинжинеринг и вообще, свое гомно не пахнет, да? Впрочем, чего еще ожидать от людей которые делают "power management" путем дрюкания интерфейса вверх-вниз, и игноря кучу проблем которые при этом будут? Как то никаковская латенси, риск отвала соединений и потери ремотных пакетов, непригодность для listen режима и прочая.
> 1. Кто будет определять формат сообщений?
По логике вещей - те кто собираются отправлять и получать сообщения этого типа. Если бы это было нерешаемой задачей, мы бы тут переписываться не смогли. Догадываетесь почему? :)
И кстати d-bus как таковой появился в том числе и для того чтобы програмеры не сношали себе мозг низкоуровневой формировкой пакетов. Мало кто коммуницирует с сервером, например, опеннетом, самолично выкраивая все кадры эзернета в своей программе.
> 2. Как убедить всех использовать единый формат сообщений?
В жестком виде ессно никак. А по факту какая-то из реализаций станет стандартом де-факто, основная масса софта это станет понимать. А как там особо хитрый мамонт будет дрoчить сетевым интерфейсом туда-сюда потому что это в его понимании и есть power management, это уже проблемы этого мамонта (варианты для этого всегда найдутся). Ну то-есть вы можете любить IPX хоть до поросячьего визга. Но послать пакеты мне по нему не сможете. Потому что я и промежуточные роутеры его не понимаем. Будете пользоваться TCP/IP и HTTP. Или пойдете нафиг. На выбор. Но разумется приказать вам использовать именно TCP/IP и HTTP никто не может. Просто вы будете взаимодействовать только сами с собой, если перестаратетесь с кастомом.
> 3. Что делать с программами не умеющих/не желающих/игнорирующих сообщения?
Ничего. Если кому-то станет это надо - они пойдут и сделают так чтобы умели и не игнорировали. А на нет и суда нет.
> 4. Что делать если программ запущенна после прохождения сообщения?
А это как с IRC. Вы присоединились к каналу. Но сообщения уже пролетели. Что делать? А ничего. Если это что-то критичное - ну давать по сусалам на потуги например врубить вафлю в самолете. Т.е. пока самолетный режим явно не снят - фиг вам а не вафля.
> 5. Что будет если несколько программ попытаются выключить/включить один и тот же
> интерфейс?
По логике вещей, кто последний попросил сделать нечто с интерфейсом, тот и определил конечный результат. Да, в принципе там возможны грабли. Ну вот раз вы такой умный - вот и расскажите как ваше дрoчиво интерфейсом для экономии питания этот вопрос решает? :) А то вы хитрый - своим горбылям скидку сделали, а с остальных, значит, спрашиваем по полной, так? :)
> 6. Потребление памяти и усложнение программ - им всем придется уметь принимать
> сообщения и корректно их обрабатывать.
Не "всем" а "заинтересованным в этой категории сообщений". И да, конечно, куча скриптов постоянно дрoчащих интерфейсы вверх-вниз как ваше "управление питанием" наверное память и проц не занимают, да? Ну я понимаю что себе - скидки :)
> 7. Сколько понадобится человеко-часов на внедрение и отладку этого?
Не так уж много. И меньше чем сумма человеко-часов на костылирование на каждой машине у каждого юзверя совершенно типовых вещей. И вообще, этой проблемой как видим нашлось желающих заняться - вам то какое дело до их человеко-часов?
