> Проверка на ошибки, да. А дать механизм, который бы ошибку предупредил -
> религия не позволяет?Пока не вижу ситуаций, где это действительно былобы оправдано.
> Я предлагаю оставить проверку ошибок в покое, а при возможности - уведомлять
> приложения о различных событиях/изменениях состояния как можно раньше. Чтобы (по крайней
> мере в штатном случае) не молча обрывалось соединение в самый неподходящий
> момент,
Потеря пакетов или сигнала (3g/wifi) вполне обычная ситуация и должна быть обработана корректно.
> когда приложение будет ждать ответ на DNS-запрос пол-минуты (и, соответственно,
> крутить индикатор ожидания пользователю). В ряде случаев это не поможет -
> но в большинстве ситуаций - улучшит user experience.
Ждать оно будет только в одном случае - пока есть хоть какая-то надежда получить данные. Если сеть погашена, то реакция будет мгновенной. Погасите интерфейс с гейтом и попробуйте открыть что-нибудь в браузере.
> Нет, если на диске вырос relocation, или ещэ как SMART ругнулся -
> это не повод паниковать и уходить в readonly и нарушать какие-то
> важные активности пользорвателя. Но это вполне себе повод: 1) уведомить пользователя,
> что диск не особо надёжен
Конкретную реакцию должен определять администратор.
> 2) до его решения ограничить незначимый
> но интенсивный I/O. И уж точно принятие решения, что надо ограничивать
> и какие меры принимать - дело отнюдь не ядра, а либо
> самого приложения, этот I/O осуществляющего, либо работчего окружения, держащего общую
> конфигурацию.
Такой подход не приемлем. Мы получим либо тормоза, либо продолжение активного i/o. Приложения сами по себе ничего не должны решать. Должна быть задана конкретная реакция на конкретную проблему. Оставлять такие вещи на усмотрение программ и наедятся что авторы были не дураки и все продумали как минимум наивно. Всегда найдется та программа, которая проигнорирует подобное сообщение.
> С дисковыми квотами результат тот же - какой смысл загонять приложение в
> нештутную (даже если и обрабатываемую) ситуацию? Сидит, значит, пользователь, обрабатывает
> здоровенный графиечский файл - и вдруг выясняет, что сохранить он его
> не может - не важно, места нет или приложение/пользователя квотами обрезали.
По-вашему сейчас приложение не может проверить/зарезервировать свободное место, до начал операции? Насколько я помню тот же transmission заранее предупреждает, если на разделе заканчивается место.
> А А обработать прозрачно - религия не велит? Чтобы, допустим, рядом
> сидящий браузер кэш от недавно просмотренных видео почистил?
1. Если я задаю размер кэша вручную, значит я хочу что бы его размер таким и был, вне зависимости хватает остальным места или нет.
2. Если размер кэша стоит авто, то браузер должен при малейшем намеке на нехватку места урезать кэш. Насколько я знаю, так сейчас и происходит.
ИМХО вполне нормальная практика просто оповестить пользователя, о том что место заканчивается. А уж что лучше удалить он решит сам. А то получится, что пользователь смотрел online фильм и копировал тучу фильмов на съемный диск. Но лажанулся и отправил не на тот диск. Сперва у него начал дергаться фильм, так как удалился из кэша, а затем все равно кончилось место.
> И, соответственно, речь не об audio, а обо всём спектре событий -
> от информации от железа до соообщений, отосланных из пользовательского скрипта.
Я не отрицаю, что где-то это может быть полезно. Но призываю лишний раз подумать, а надо ли оно в конкретной ситуации.
