История изменений
Исправление dimgel, (текущая версия) :
Во-первых, convention over configuration – злое зло.
Это почему ?
Потому что не контролируется компилятором. В т.ч. никаких подсказок от IDE в процессе написания кода, никакого битья по рукам если что не так. Т.е. нужно дохрена помнить самому. И если convention вдруг поменяется, ты узнаешь об этом только когда твоя программа рухнет.
Как по мне, концепция «оба приложения общаются друг другом через установленное соединение сквозь посредник»
Где в сокете посредник? Ядро, передающее данные от отправителя к получателю? Гы, а файлы создаются сами, без ядра, святым духом?
избыточнее концепции «хотящее в трей приложение помечает кладет себя в папку, хотящие вывести трей приложения читают папку» :)
Как часто читает папку, чтобы вывести? Или мы теперь ещё и inotify(7) должны заюзать, чтобы ядро нас уведомляло сразу же как только кто-то запишет файл? По сравнению с тупой передачей данный между процессами, тут лишних движений на порядок-другой больше – и в приложении, и в ядре (не забываем про количество syscall-ов).
реализация шины нелогичная и непонятная с кучей шелухи
Выше я про обычный сокет с кастомным протоколом (или например, как чуть выше написали, с тем же x11). В dbus я пару раз пытался вгрызться – и плюнул. Дикая дичь. Мне не нужно было с чужим софтом коммуницировать, а сам с собой я и попроще могу договориться. %-)
Исправление dimgel, :
Во-первых, convention over configuration – злое зло.
Это почему ?
Потому что не контролируется компилятором. В т.ч. никаких подсказок от IDE в процессе написания кода, никакого битья по рукам если что не так. Т.е. нужно дохрена помнить самому. И если convention вдруг поменяется, ты узнаешь об этом только когда твоя программа упадёт.
Как по мне, концепция «оба приложения общаются друг другом через установленное соединение сквозь посредник»
Где в сокете посредник? Ядро, передающее данные от отправителя к получателю? Гы, а файлы создаются сами, без ядра, святым духом?
избыточнее концепции «хотящее в трей приложение помечает кладет себя в папку, хотящие вывести трей приложения читают папку» :)
Как часто читает папку, чтобы вывести? Или мы теперь ещё и inotify(7) должны заюзать, чтобы ядро нас уведомляло сразу же как только кто-то запишет файл? По сравнению с тупой передачей данный между процессами, тут лишних движений на порядок-другой больше – и в приложении, и в ядре (не забываем про количество syscall-ов).
реализация шины нелогичная и непонятная с кучей шелухи
Выше я про обычный сокет с кастомным протоколом (или например, как чуть выше написали, с тем же x11). В dbus я пару раз пытался вгрызться – и плюнул. Дикая дичь. Мне не нужно было с чужим софтом коммуницировать, а сам с собой я и попроще могу договориться. %-)
Исходная версия dimgel, :
Во-первых, convention over configuration – злое зло.
Это почему ?
Потому что не контролируется компилятором. В т.ч. никаких подсказок от IDE в процессе написания кода, никакого битья по рукам если что не так. Т.е. нужно дохрена помнить самому. И если convention вдруг поменяется, ты узнаешь об этом только когда твоя программа упадёт.
Как по мне, концепция «оба приложения общаются друг другом через установленное соединение сквозь посредник»
Где в сокете посредник? Ядро, передающее данные от отправителя к получателю? Гы, а файлы создаются сами, без ядра, святым духом?
избыточнее концепции «хотящее в трей приложение помечает кладет себя в папку, хотящие вывести трей приложения читают папку» :)
Как часто читает папку, чтобы вывести? Или мы теперь ещё и inotify(7) должны заюзать, чтобы ядро нас уведомляло сразу же как только кто-то запишет файл? По сравнению с тупой передачей данный между процессами, тут лишних движений на порядок-другой больше – и в приложении, и в ядре (не забываем про количество syscall-ов).
реализация шины нелогичная и непонятная с кучей шелухи
Выше я про обычный сокет с кастомным протоколом (или например, как чуть выше написали, с тем же x11). В dbus я пару раз пытался вгрызться – и плюнул. Дикая дичь.