это 15 кб без gzip, или 11 кб в gzip. это проблема?

если следить через веб-интерфейс, то каждый переход по странице, без кэша - съест гораздо больше.

для распределённой системы, понятное дело, нужны ВСЕ хэши. потому что сообщения могут приходить откуда угодно, в каком угодно порядке. вы вообще когда-нибудь hg push/hg pull делали? видели, сколько там разных запросов туда-сюда бегает.

ну сделай меньше поллинг, и делов. в фидо поллинг раз в полчаса был нормальным, а если постояннно названивать - нод мог и по шее настучать. это же система обмена офлайн-сообщениями - пакетно принял, пакетно отдал. основное назначение - не одна эха ни о чём, а десятки, а в перспективе сотни, тематических эх, где спокойно принял всё, спокойно почитал, спокойно ответил, отправил.

> Зачем?

чтобы система обмена двумя списками оставалась системой обмена двумя списками, и ничем более. плодить неоднозначности - это вылезет боком в отладке других клиентов и серверов. вот это точно не имеет смысла - реализация должна быть ПОВТОРЯБЕЛЬНАЯ и ОЧЕВИДНАЯ, чтобы даже девочки на уроках труда вязали спицами клиенты. тем более, http-запросы это вещь такая, со всеми её заголовками, что если постоянно будет два запроса вместо одного, то никакой экономии не выйдет.

> это 15 кб без gzip, или 11 кб в gzip. это проблема?
Если куча подписок, то это, к примеру, 300 кб без gzip и 200 с gzip. На телефоне это очень большая проблема, тем более, по gprs. Даже если в эху никто не написал, всё равно приходится скачивать такие объёмы. Таймстампы очень сильно экономят трафик.

для пойнта не всё равно. изначально оно вообще по одному сообщения собирала - это было долго и скучно.

а подобные расширения, которые позволяли делать всякое - были, раньше. к счастью, их всех убили :) это отягощало описание api - сейчас я его могу в трамвае кому-нибудь рассказать на словах :), раньше - нет. оно не решает никаких проблем пользователей. оно заставит ВСЕ, КТО ХОЧЕТ БЫТЬ ОФНОДОЙ, повторять все эти вещи, иначе какой-нибудь клиент не будет работать.

нужно, чтобы писать клиенты было легко, писать серверы - легко, для пользователя чтобы было удобно, неоднозначностей должно быть меньше, все клиенты должны быть совместимы со всеми серверами. и модульность, и модули - должны будут нуждаться в поддержке, в документации, в реализациях. при этом, это плодит неоднозначности для тех, кто не понимает, зачем это, и не решает никаких реальных проблем пользователей (про трафик мне не надо - если есть движение, то придётся ВСЕГДА запрашивать весь список, иначе ii или другая распределённая вещь не работает, в принципе), а если нет - то зачем поллить ежесекундно и при этом

ii против программистов! :) и технологичности :) потому что это всегда вырастает в овертехнологичность, фичи добавляются по "хочется добавить фичу", а не по нужде.

сейчас есть только одна опциональная вещь - /u/push. потому что она нужна реально, в самом реальном примере использования системы. без неё не обойтись. а без каких-то систем предзапросов - можно обойтись легко. оно уже не один месяц работает, и работает нормально. в фидо тоже оверхеда хватало. а всё лучшее, что тут есть - взято из фидо, где оно доказало свою практичность и эффективность десятилетиями.

Да, это проблема. Опросить 10 эх и потерять 130 кб мобильного трафика? И уж конечно проще напрягать gc на телефоне, чем дать возможность нодам делать кастомные расширешия без ломания основного протокола.

Мобильный клиент в систему обмена офлайн сообщениями слегка не вписывается, или ты предлагаешь в твоей плейн-текст-базе хранить историю эх на телефоне? Прощай, карта памяти.

Я напоминаю, речь идет о мобилках и планшетах.

Да какая офнода на телефоне, ты себе как это представляешь?

да можете хоть гей-парады строем проводить, но только у себя. мне зачем это писать, да ещё не в первый раз?

> Если куча подписок, то это, к примеру, 300 кб без gzip и 200 с gzip.

не могу спроецировать это на фидо. кроме как анекдотом про блондинку и голдед "а что, их читать надо? а я в нестеренкину игру Фидо играла, там сообщения сами читались".

если у тебя такое число подписок, то ты вообще не попадёшь в идентичные эхи, и у тебя ВСЕГДА будет два запроса вместо одного. если, конечно, ты не поллишь раз в 5 секунд, а сообщения не читаешь.

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

Тикакие таймстампы ничего лучше в данной ситуации не сделают. чтобы понимать, как работают такие сети, какие там принципы поллинга и хождения сообщений, и так далее - нужно просто знать это. те, у кого нет нескольких лет фидошного опыта в 90-х - 2000-х годах, просто не пишите мне ничего на эту тему, ладно? я признаю ваше право быть самыми умными, и решать эмпирическую проблему не на статистике, а на "я вот тут придумал", и на этом же и оставайтесь. Мне надоело один и тот же бред в десятый раз комментировать, причём безо всякого эффекта с той стороны.

> Мобильный клиент в систему обмена офлайн сообщениями слегка не вписывается, или ты предлагаешь в твоей плейн-текст-базе хранить историю эх на телефоне? Прощай, карта памяти.
> Я напоминаю, речь идет о мобилках и планшетах.
Оффлайн обязательно нужен и очень полезен на телефоне

Мда, т.е. ты утверждаешь, что запрос вида:

/x/t/echo1/echo2/.../echo-n

который вернет n строк с версией базы
ВНЕЗАПНО не лучше чем постоянний поллинг?

Давай после этого прекратим обсуждать это. Идею я предложил не с потолка, она используется в Dns

Оффлайн кучей-файлов-на-карте убьет её. Имхо. Единственный нормальный вариант для меня - хранить в sqlite, которая крутится на каждом телефоне

> Мобильный клиент в систему обмена офлайн сообщениями слегка не вписывается, или ты предлагаешь в твоей плейн-текст-базе хранить историю эх на телефоне? Прощай, карта памяти.

чувак, ты не поверишь, но я читал сообщения с офноды, в офлайне, ещё тогда, когда она только появилась

через rss-клиент. причём тут вообще плейн-текст? кого волнует, в плейнтексте или нет хранится база? какое это вообще имеет значение.

> Да, это проблема. Опросить 10 эх и потерять 130 кб мобильного трафика?


> И уж конечно проще напрягать gc на телефоне, чем дать возможность нодам делать кастомные расширешия без ломания основного протокола.

ты не видишь проблему. просто смотришь не туда. и ты уткнёшься потом носом в эту проблему, которую я написал. я уже не одну статью написал, про то, почему недовольные будут неодовольны, но не увидят проблем, не увидят в принципе, потому что требуется сдвиг парадигмы мышления, чтобы это увидеть и осознать. и что будут спотыкаться там и там.

а у меня, моя реализация, работает с первого раза, и БЕЗ ПРОБЛЕМ. и тот, кто будет это повторять, по правилам, у того тоже ПРОБЛЕМ НЕ БУДЕТ. вот это - важно. лишние 100 кб трафика (в день? в неделю? в месяц?) один фиг, это всё СОПУТСТВУЮЩИЙ трафик, и почти всегда соотношение этих списков к сообщениям будет примерно одинаковым ПРОЦЕНТОМ, если ты не делаешь полинг каждые две секунды. То есть, на X кб сообщений - Y% +- сопутствующего трафика. это вытекает из природы сети и правильной её организации. не нужно тут трясти чистыми процентами. ты ещё на html пожалуйся, что каждый раз, когда ты загружаешь текст, тебе ещё лишние тэги загружаются. или на rss, там тоже есть оверхед. это бред, и бред откровенный.

> И уж конечно проще напрягать gc на телефоне, чем дать возможность нодам делать кастомные расширешия без ломания основного протокола.

если у нодов что-то чешется, то пусть пойдут и почешут, в туалете. плодить неоднозначности и потенциальные проблемы ради того, чтобы кто-то делал поллинг раз в две секунды - не имеет смысла. если ты не видишь этих неоднозначностей и потенциальных проблем - то проблема только в тебе. а начинать следует с того, что в распределённой сети идея с таймстпамом, как и вообще со сравнением на больше-меньше - работать не будет. ни в фидо, ни в hg, ничего подобного нет - но это не от того, что там идиоты сидят, которые ничего не понимают.

у нас уже были проблемы с отладкой сторонних вещей, когда плодятся неоднозначности. если добавлять к ним ещё проблемы - загребётесь всё отлаживать. цель именно сделать протокол простой, как палка. которым можно пользоваться. а не страдать от того, что там какие-то частные случаи не обрабатываются. и никогда не будут обрабатываться, потому что потенциальные проблемы - не нужны, реальных хватает. нужно делать всё хорошо и правильно с первого раза, чтобы и потом всегда всё работало. а не делать разные виды нод, где кто-то с кем-то совеместим, а кто-то - нет. совместимость и беспроблемность и очевидность ВАЖНЕЕ 130 кб СОПУТСТВУЮЩЕГО трафика.

> Мда, т.е. ты утверждаешь, что запрос вида:
> /x/t/echo1/echo2/.../echo-n
> который вернет n строк с версией базы
> ВНЕЗАПНО не лучше чем постоянний поллинг?

тебя бы в фидо часто били. по морде. за такие замашки.

или пойди на гитхаб, и сделай там постоянный поллинг хотя бы 5000 репозиториев

ты вообще понимаешь, что такое ФИДО? и почему на главной написано "помесь фидо и git"?

> Оффлайн кучей-файлов-на-карте убьет её. Имхо. Единственный нормальный вариант для меня - хранить в sqlite, которая крутится на каждом телефоне

разницы между кучей файлов и sqlite - для ноды ровно 0. для клиента ровно 0.

sqlite - это и есть офлайн-база. закачал её сообщениями, уехал в тайгу и читаешь.

Разница в физическом способе хранения

Ничуть не убьёт. У меня официальный клиент на телефоне ничего плохого с карточкой не сделал. Как предложили ранее, можно и sqlite взять - разницы нет

причем тут гитхаб, это вообще совершенно другой юзкейс. Тут речь не о VCS, к системам обмена сообщениями другие требования.

> Разница в физическом способе хранения

физический способ хранения не имеет значения. его вообще не существует - лишь бы на запрос об msgid выдавала нужное сообщение. и всё.

разумеется, всё это расчитано на то, что при росте числа общих сообщений, да при наличии архива - оно будет завёрнуто в базу данных или другой способ. при этом в работе ноды и клиента совершенно ничего не изменится.

это никак не связано с "офлайн". офлайн - это значит "вне сети". в фидо твоё отправленное сообщение через цепь роутинга ходило столько, что первый ответ (если это не с твоей станции) приходил примерно через сутки (ну, стоит учитывать и разницу во времени с 5020, и то, что станции работают в основном ночью - в самой 5020 это достигало нескольких часов - и тогда, когда сеть была молодой и с малым количеством пользователей, и когда там были десятки тысяч станций с сотнями пойнтов на многих из них).

но фидо - это тематическая сеть. там даже болталки были тематические - либо локалки ноды. вся эта специфика сохранена и в ii.

> причем тут гитхаб, это вообще совершенно другой юзкейс. Тут речь не о VCS, к системам обмена сообщениями другие требования.

в данном случае мне пришлось делать свою реализацию, потому что hg/git меня не удовлетворяла по одному-единственному параметру. по всем остальным - устраивала полностью, и если бы не он - взял бы её, а не делал ii.

ты не сможешь сделать порох непромокаемыми или обмануть математику. или дудочка, или кувшинчик. или отказ от распределённости, или некорректная работа в некоторых случаях, или тебе всегда нужен полный список. при этом, на практике - частные случаи не настолько частные, чтобы иметь вообще хоть какое-то значение для трафика. мне это понятно уже сейчас.

это именно vcs. только с одним отличием - порядок следования списков.

Я не буду тебе объяснять как работает фс. Еще раз скажу про физический способ хранения базы, формат базы, структура базы, я не знаю какой из кейвордов наконец заставит тебя понять меня и перейти к конструктивному диалогу, а не срачу в стиле "Вы все говно, а я д'артоньян ибо я сделал уникально" и "а раньше все было не так, трава была зеленее, а люди добрее".

Впрочем, это уже не актуально.

Я предложил свой вариант, как дать всем возможность сделать из ii то, что они хотят, будь то IM, чат, форум, но сохранить возможность использовать это все как есть сейчас. Ты говоришь что идеи говно, что я смотрю не туда и т.д. При этом, ты говоришь, что все кинулись велосипедить. Интересно, почему же?
Хорошо, пусть так, значит я жду от ii что-то другого, чем оно не является. Ну как будет время, запилю свой велосипед, раз не получается помочь существующему проекту, если останется интерес.

И кстати, DNS - распределенная система.

> Я не буду тебе объяснять как работает фс. Еще раз скажу про физический способ хранения базы, формат базы, структура базы, я не знаю какой из кейвордов

причём здесь это и офлайн? какая разница, что и как хранится. главное - что как представляется.

> а не срачу в стиле "Вы все говно, а я д'артоньян ибо я сделал уникально"

за базаром следи. а то как бы не пришлось сменить клавиатуру на костыли, и там уже делать уникально.

всё было сделано либо как в фидо, либо как в git/hg. я не вижу там вообще ни одной уникальной идеи, проверенной практикой.

> Я предложил свой вариант, как дать всем возможность сделать из ii то, что они хотят, будь то IM, чат, форум, но сохранить возможность использовать это все как есть сейчас.

на первой странице проекта написано, почему этого не будет. свой вариант - сколько угодно. а эталон должен быть эталоном.

> Ты говоришь что идеи говно, что я смотрю не туда и т.д.

скажи, ты ебанутый или прикидываешься? чё ты всё время за ахинею несёшь? ты вообще, хотя бы для разнообразия, хоть раз пробовал прочитать и посмотреть, что я тебе пишу? о чём вообще речь? да пусть это самая замечательная идея в мире, но проблема то в другом. я лично за свою жизнь видел изнутри не менее 10 проектов, которые были, наверное, перспективны, где было куча идей, но не было целостности, где была овертехнологичность и никто не понимал, как это работает, и в какой-то проблем эти проблемы набрасывались каскадно, что было непонятно что решать. вот именно эту проблему решает мой стандарт. всё остальное - из твоей головы. меньше читай сайты со штампами для долбоёбов, которые из любого человека долбоёба сделают, и потом он будет эти штампы за истину принимать.

я тебе говорю - лучше худой стандарт, который будут соблюдать абсолютно все, чем свобода реализовывать каждому что-то по своему, что потом, чем дальше от стандарта, тем больше будут не понимать друг друга клиенты и серверы (ты сам, блядь, сам видел, что уже у кого-то нет list.txt, и это только первая сторнняя нода. при этом уже есть клиент, который использует list.txt для подписки/отписки). а ты мне талдычишь "зачем нужна нода для телефона".

с чем конструктивно говорить? с набором штампов и стереотипов в твоей голове? так я и их и так знаю, без тебя, могу даже пересказать. проблема только в том, что эти штампы, подходя ко всему формально, не подходят ни к чему реально, и они от практики вообще далеки, а от решения неочевидных проблем - тем более. это лучше ты мне скажи, зачем я эту хуйню выслушиваю, да ещё в десятый раз? ты можешь нормально обсуждать реальные вещи, которые уже есть, целиком. а не отделять 11 кб трафика списков от самих сообщений, потом перемноживать из зачем-то на 10 или 20, и потом этими цифрами трясти? это, что ли, конструктивный разговор, по твоему?

> Хорошо, пусть так, значит я жду от ii что-то другого, чем оно не является.

полем для экспериментов оно не является. всё уже придумано до нас, в git и в fido. поэтому даже клиент самой-самой первой версии, быстро набросанный, до сих пор может получать почту с официальной ноды (с отправкой есть некоторые проблемы, впрочем, очень легко исправимые).

я бы тут применил выражение "дух openbsd". они с первого раза сделали хорошо, у них за эти годы вообще практически ничего не поменялось, и где сразу и с первого раза было сделано хорошо :) и да, им тоже постоянно приходится выслушивать кучу долбоёбов, кричащих "нахрен cvs, нужен git", которые вообще понятия не имеют, что при этом получится, что потеряется, а мыслят совершенно поверхносттно, и не имея серьёзного личного опыта ИСПОЛЬЗОВАНИЯ, просто "для меня лучше, значит и для других лучше".

> И кстати, DNS - распределенная система.

я знаю. только это онлайн система. она без tcp/ip вообще не работает. для ii даже сеть не нужна, можно флоппинетом обмениваться. или встраивать системы "вброса в базу", да хоть через qr коды или азбуку морзе. в общем - простота предполагает гибкость. а гибкость - примеры использования, которые раньше даже в голову не приходили. и при этом нужен компромисс с практичностью. и между "сопутствующий трафик" и "не городить огород, который редко когда будет работать по написанному тут", я выбираю, разумеется, первое - оно практичнее.

парень, ты упорот? Я тебе десятый раз говорю, речь не о представлении, а о физическом хранении базы на телефоне! Причем тут нахер представление, если ты в любом случае будешь писать интерфейс для чтения данных из базы?

Ты мне про ебанутость говоришь? Я сколько сообщений назад тебе сказал, что чтобы не было кучи несовместимых реализаций взять твой стандарт за эталон и сказать "а вот с запросом /xyz делайте что хотите в ваших реализациях, он вам на откуп, но помните, что поддерживать его никто не обязан но блять может"?

Себе смотри ничего не сломай.

> парень, ты упорот?

то есть, за базаром ты следить принципиально не хочешь? один твой сленг выдёт в тебе очередное дитя интернета, и я прекрасно понимаю, что ты скажешь, почему ты скажешь, и даже где ты узнал эту нехитрую мысль. поэтому твоего мнения тут 0. ноль. не не предоставляешь самостоятельности.

> Причем тут нахер представление, если ты в любом случае будешь писать интерфейс для чтения данных из базы?

это вообще ПОСЛЕДНЕЕ, что кого-то интересует что в реализации сервера, что в реализации клиента. какая вообще, в пизду, разница, как оно хранится? это хоть что-то значит в обмене клиента и сервера. они обменялись и разошлись... а как ты хранишь, всем вообще наплевать. это вообще не имеет значения к реализации, как бы оно не было сделано.

ты точно так же можешь верещать "процессоры сделаны из кремния! понимаешь, из кремния!". с точно такой же информативностью.

> Ты мне про ебанутость говоришь?

тебе. потому что ведёшь себя, как ебанутый.

> "а вот с запросом /xyz делайте что хотите в ваших реализациях, он вам на откуп, но помните, что поддерживать его никто не обязан но блять может"?

как жаль, что вы выходили, когда я объяснял прошлый раз. и позапрошлый тоже.

> Себе смотри ничего не сломай.

ты, дятел, довыёбываешься.

Я не вижу смысла дальше продолжать это обсуждать. Моё дело было предложить, твое отказаться. То что мне нужно было от проекта, я получил.

я сейчас вообще не имею отношение к ii, ничего там не решаю

я объяснял, почему было сделано так, а не иначе, и почему оно, собственно, худо-бедно выжило, несмотря на то, что постоянно вокруг болталось куча умных, которые, перечитав интернета, решили, что принимать решения - это круто, а последствия - это для лохов.

сейчас у меня своя реализация. там есть куча расширений, моих собственных, для собственного решения. если бы ты читал ещё, что тебе пишут...

Очень хорошо

Прости, брат ntrknlmp, я немного переусердствовал в подаче матерала, неподобающе настоящего ii-янина себя вёл. :(

Ничего страшного, все в порядке, и ты меня прости.

Ну как сказать не сделает.
У NAND (встроенная память в телефоне, которая распаяна физически на плате) ограниченное кол-во циклов перезаписи, у SD кард тоже. Но, блин, это флешка, хрен с ней, выкинуть и новую купить. А NAND не поменяешь.
Я так доигрался уже с накатыванием образов линукса на свой трансформер, в один прекрасный момент появились bad-block'и в андроидовской /data и все, бутлуп.

Плюс вспоминается такое явление, как внутренняя фрагментация ФС. Не знаю, насколько сильно ей подвержена ext.

Я пока что придерживаюсь мнения, что лучше хранить в sqlite, но там есть какое-то ограничение на кол-во строк в курсоре, надо искать подробности и тестировать. Может имеет смысл хранить только определенное число последних сообщений.

Читать "оффлайн" можно и сейчас, если GC не будет инициировать сборку мусора (для текущей эхи - не будет, для соседних может). Отвечать в оффлайне - я себе это представляю как буфер сообщений в памяти отдельного сервиса, который при появлении коннекта будет отправлять сообщения на сервер и завершаться. Но опять же это все для того, чтобы не писать ничего в storage.

Повторюсь, прикручивать базу (и полноценный офлайн соотв-но) буду, но позже и как опцию.
А пока что будет использоваться hashmap в памяти.

Надо много думать, пробовать и смотреть как лучше.

Что так, что так будет запись. Но лучше база на телефоне, конечно, потому что всего один файл, а не тысяча, разбираться легче. Лучше sqlite, конечно тогда брать. Удалять сообщения тоже потом можно будет.

Не, если хранить в памяти, то записи не будет) Статическая переменная будет жить, пока жива программа.

А так да, скуль на текущий момент выглядит лучшим выбором. Тем более он стандартный для системы.

возьми у меня на гейт эху od.ii.dev.14 (она пока пустая), будет заменителем vk :)

я там про "распредпортал" что-нибудь набросать попробую - кому интересно, пусть тоже подпишутся.

кстати, а кто вообще у тебя фетчи дёргает. я так понимаю, ленина тоже мне прописывать в свой крон, или оно у тебя дёргается?

У меня используется объектная модель, плэин текст конвертируется в обьекты типа "Сообщение". Это не полноценная нода, это именно клиент, он не может работать без ноды.
Ничего не мешает прокрутить поддержку чего душа желает, но давай этим займемся после того, как сделаю рефакторинг кода:)
Подготовь пока описание api своей версии ii

> Не, если хранить в памяти, то записи не будет) Статическая переменная будет жить, пока жива программа.
Не, память надо освобождать время от времени. И процессы (приложения) лишние прибивать. А ещё перезагрузка есть. Поэтому однозначно нужно хранение в постоянной памяти.

Убедил:)

> кстати, а кто вообще у тебя фетчи дёргает. я так понимаю, ленина тоже мне прописывать в свой крон, или оно у тебя дёргается?
Не знаю, кто дёргает. Видимо, это ты дёргаешь, раз Ромеро Яковлев появляется. Пропиши-ка ленина в свой крон.

Ок, пропишу. Будем теперь там общаться. Меньше поводов в вк заходить.

я вручную страницу в браузере по f5 обновляю

пропишу

>Единственный нормальный вариант для меня - хранить в sqlite, которая крутится на каждом телефоне

Я почему-то думал, что у тебя в клиенте и так sqlite...

Кстати, схему sqlite и алгоритм(хреновый, конечно же) можешь у меня посмотреть.

Нет, пока что все в памяти хранится:)
Хорошо, как руки дойдут до базы - гляну:)

подпишись на ту эху. а от этой я отпишусь у себя в интерфейсе, пусть в фоне жужжит :)

Скоро выложу новый билд

Совсем скорррро)

Обновление клиента

https://yadi.sk/d/DdoT9BbcTxPB7

Изменения:
* Теперь при обновлении сообщений будут загружаться только новые.
* Добавлен механизм уведомлений. При активации, клиент переодически скачивает список сообщений и сверяет с локальной загруженной ранее копией. Проверяются все эхи, из которых были загружены сообщения. Интервал проверок задается в настроках.
* Теперь в списке сообщений выводится дата и время.
* Немного изменен интерфейс.

Примечания:
* Проверка наличия новых сообщений и соответственно появление уведомлений будет происходит даже если клиента закрыт. Поведение, при котором проверка наличия новых сообщений прекращается при закрытии окна программы, будет реализовано позднее.

А есть возможность список эх скрывать на время чтения?

Хорош клиент, но где же исходники? :)

> Обновление клиента для андроид

обновил на http://apk.51t.ru

Я уже говорил свою позицию по поводу исходников:) ну не будете вы сейчас сидеть и разбираться в этих костылях и подпорках:) При такой скорости разработки о качестве кода говорить смысла нет
Бекдоров он АНБ не внедрял, чесслово)

> Я уже говорил свою позицию по поводу исходников:) ну не будете вы сейчас сидеть и разбираться в этих костылях и подпорках:)
А нам интересно, поэтому будем =)
> При такой скорости разработки о качестве кода говорить смысла нет
Понимаешь, тут каждый программирует, как может. Думаешь, у нас код прямо таки идеальный? =) Да и вообще, исходники нужны на случай, если ты, к примеру, уйдёшь, или ещё что случится. Есть гарантия, что мы сможем самостоятельно продолжить разработку.