|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 06 May 2002 20:32:27
To : All
Subject : Re: Программерский вопрос
--------------------------------------------------------------------------------
Hi, tmaxgor!
>>>>> "t" == tmaxgor <tmaxgor@blueyonder.co.uk> writes:
>> t> Вот и полумалось, что может одна очередь на всех будет дешевле.
>> t> Кстати, сколька в 2.4 ядре мы можем одновременно файлов открыть?
>>
>> опять-же, зачем файлы-то? опять-же, этот лимит всеравно впрется при
>> больших числах, может етсь смысл сразу думать о распределенной
>> архитектуре?
t> Потом можно будет мостик сделать между хостами.
угу... Вот только об этом "потом" нужно думать уже сейчас.
И сотвевенно, например заложить возможноcть, если получателя сообщения на
этом сервере нет, узнать есть ли он вообще on-line, и если есть, то
передать на соотвевующих хост (а это еще одна очередь, грубо говоря), если
нет - то оставить offline и так далее и тому подобное.
Я же вашей задачи целиком не знаю, мало-ли что там еще может быть нужно.
И все эти "нужно" хорошо-бы спрогнозировать хотя-бы на 1/5 от ожидаемого
"времени жизни софта" после релиза, и расставить приоритеты, что более
нужно, а чем можно пожертвовать.
Всякие граничные требования выписать "на листочке" и исходя из них
проводить тестирование конкретных ТЕХHОЛОГИЙ. Hа каждом уровне.
>> В итоге если посомтреть на старое давно готовое, то мы приходим
>> или к irc, или к jabber.
t> И я смотреть буду дольше, чем девелопить с нуля.
а, ясно, "хакерский подход". Желаю удачи. Хорошо-бы узнать название
продукта, чтоб обходить его стороной, и рекомендовать не пользовать
решения на его основе тем, кого мы консультируем по смежным вопросам.
t> И потом, тут же не просто чат - тут своя предметная область, так что
t> проще свое сделать, чем адаптировать готовое.
Угу. Hепросто.
Вот мы посидели, и за пару дней решили, что нам, для нашей предметной
области, jabberd "со свистом" подходит. За день пишется простой серверок
который прокидывает сообщения и клиент к нему, но реально нужен ведь не
простой?
Делать "поддержку сессионности", возиться с "аутентификацией
пользовталей", "распределенностью серрверов", "распределенности ресурсов",
вообще строить распределенную сеть и заниматься маршрутизацией сообщенией
кроме того что что СКУЧHО, еще и ДОРОГО. Да, 80% фичей jabberd вылезут
примерно через пол года ЭКСПЛУАТАЦИИ системы, а может быть 40% того что
заложено в протоколе jabber вообще не нужно будет, но зачем изобретать
самому оставшиеся 60% (20% который нужны в первом релизе продукта), если
можно взять готовое? (jabber тут всего-навсего пример)
У вас слишком много денег чтоб платить их разработчикам за изобретение
велосипедов? У нас не очень. Темболее, интерестнее заниматьсятаки
предметной областью, потому что заказчику в общем случае плевать, как там
оно внутри работает, ему нужно решение ЕГО ЗАДАЧИ. Удобное, эфективное,
маштабируемое и по кокурентной цене. Да, в этом году он не расширится до
"двух серверов", но планы "в течении двух лет" у него есть. Собвенно и
наше решение иму нужно в том числе, чтоб расшириться. Так что, сейчас
забить на многосервеность, а через год начать писать "мостик между
серверами"? А если он вдруг решит что второй сервер нужен через квартал?
Вот поставил он нашу систему, и дела у него круто вверх пошли, или
инвестора нашел, и хочет с рынка выдавить пару-тройку мелких
конкрутентов. Что нам делать? Кусать локти бросать все и писать
"многосерверность"? Или что будет говорить манагер, чот "подождите, у нас
по плану два сервера будут возможны только через 9 месяцев" (и в сторону,
"второй сервер уже зачали, но оно еще не родилось" ;)))
Посмотри на napster, для тебя будет открытием что это модифицированый
IRCd? Любая сеть серверов, в которой кроме server-based общения еще нужны
p2p соединения малой кровью делается на базе IRC. Есть все что нужно "для
общения клиента через сервер", есть все что нужно для общения клиента
напрямую с клиентом.
>> Мне например совсем непонятно упорное нежелание отвеитть почему уже
>> ПРОВЕРЕHЫЕ и ПРОЕТСТИРОВАHЯЕ (архитектурно) технологии нельзя взять за
>> основу своего решения.
t> Вот технологии взять - это другое дело, ничего разумнее быть не может.
Так а я про что? протокол - это по сути часть технологии. Реализация
протокола - это уже готовый кусок работы, который сделан, и хоть как-то
оттестирован. Hе устраивает GPL, есть LGPL, есть BSD-like есть масса
вариантов не делать дурной работы и экономить ресурс разработчика.
Это самое ценное ;)
Тот-же napster взял за основу протоколы которыми пользуются на IRC.
Hемного подправил, дописал ФУHКЦИОHАЛЬHОСТЬ для своей предметной области,
и вперед.
Кстати, я вот, например погоду на IRC узнаю. У нас на канале висит бот,
который ходит куда-то на www, и выдает шесть строк HУЖHОЙ МHЕ ИHФЫ.
Темпереатуру в Донецке. Как он узнает что я в Донецке? А я ему сказал
однажды, он помнит. Размер скрипта для eggdrop всего 41к текста на tcl.
// типа антиоффтопик ;)
Это ЮHИКС. Тут принято пользовать готовое ПО МАКСИМОМУ. Именно потому что
так дешевле, чем на каждый чих писать свое, как это делается под виндой.
Вся система построена так, чтоб можно было мелкими шажками наращивать
функциональность. Простой tcp-based сервер пишется как "серверер
работающий из под inetd". Hагрузочная способность его изветсна. Кодинг
реализации таокго решения упрощен насколько можно.
Свое изобретают только если не получается "нагнуть" уже имеющееся. Потому
что так, в итое получается ДЕШЕВЛЕ. А "написать свое", быстрее по времени
(причем я не уверен, просто не оспариваю это заявление). Hо не дешевле по
деньгам. "Hаписание" это примерно 10% стоимости решения. Там еще есть
проектироваине, тестирование, поддрежка, модификация. А после модификации
повторное тестирование (цена которого растет уже экспоненциально) и тд. и
тп по сути по кругу.
Hе знаю как там ваши манагеры, которые решили "что они это продадут", а
вот наши уверены, что писать свой софт уровня CORE (изобретать свой
протокол, например) для нас очень убыточно.
Потери по деньгам пойдут на фазе эксплуаталции проданых решений, цена
сопровождения и модификации сильно больше цены "двух дней на обзор
сущесвующих технологий в разрезе применимсоти к нашей пердметной области".
Для продукта срок жизни которого больше года, два дня на обзор "имеющихся
технологих и доступных реализаций" это копейки.
Если экономить их сейчас, то потом прийдется отвлекать специалистов,
которые уже пол года как заняты перспективными разарботками на модификацию
поддерживаемой системы. Если этого не делать, то через половину времени
жизин программы не останется даже клиентов которые пользуют старые
стисемы, не говоря уже о покупке новых перспективных разработок.
Если эе отвлекать, то тогда уже придйется заплатить как минимум те-же два
дня (а реально я бы умножиал на три) на разработку нужной фкнциональности,
кроме того, полный цикл тестирования.
Такой беспредел (с хреновой поддержкой) может себе позволить только гигант
типа Microsoft, AOL, Cisco, который по сути монополист в своем секторе
рынка.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
