[room] java devel

[Денис Смирнов]

On Thu, Feb 26, 2009 at 09:14:01AM +0300, Eugene Prokopiev wrote:

EP> Система, запущенная в винде будет иметь ограничения по функционалу, а
EP> это в корне противоречит идее кроссплатформенности. Т.е. лучше уж
EP> пусть те, кому сильно надо, изобретут свои переносимые велосипеды, не
EP> связанные со спецификой UNIX.

Гм. Еще раз:

В винде обрабатываются только start/stop, потому что другого там нет. Но
если интерфейс будет также позволять реализовать, например, обработку
sighup -- это будет означать только то, что на винде этим воспользоваться
не получится, не более того. Просто сервис запущеный под UNIX будет иметь
дополнительный функционал.

Кто мешает?

EP> Кстати, штатный способ управления уже запущенным сервисом (перечитать
EP> конфиг, записать/прочитать некие переменные и т.д.) - JMX, так что
EP> проблема не особенно актуальна. В качестве клиента JMX и не только
EP> см., например, OpenNMS - его у нас даже пакетили

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

EP> А еще код commons daemon достаточно компактный и читаемый, чтоб при
EP> большом желании все-таки прострелить себе ногу ... ;)

Ох... :)

>>  Мне непонятно почему отрезают функционал который UNIX-only. Как и с UNIX
>>  sockets которые чем-то санкам не нравятся :(
EP> А вот тут можно было бы иметь идентичный интерфейс для всех платформ +
EP> дополнительную семантику для UNIX - ущерба винде не было бы, так что
EP> тут я санкам оправдания найти не могу

Ну почему же одинаковым -- параметры при создания сокета совсем другие.
При _работе с ним_ -- да, все Ok. Но приложение которое попытается на
винде открыть UNIX socket получит соответствующий exception, например.
Вполне логично, не правда ли?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------