OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 01 Октябрь, 2020 03:16

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 25 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Типичная проблема выбора.
СообщениеДобавлено: Четверг, 28 Октябрь, 2010 17:46 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Наверно лучше сюда.

Итак имею сейчас следующую ситуацию (ситуация типична для индустрии, но вот сейчас она особенно четко передо мною встала):

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

Нужно также учесть, что возможно в дальнейшем могут потребоваться некий функционал который реализован в первой программа, а во второй нет. Скопипастить код из первой во вторую нельзя -- лицензионные ограничения. Т.е. придется видимо реализовывать самому, ежели таковая потребность возникнет. Характерное время возникновения таковой потребности -- где-то полгода.

Вот сижу как буриданов осёл между этими двумя вариантами и рискую повторить его судьбу..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Четверг, 28 Октябрь, 2010 18:38 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 552
Откуда: Москва
Прибавьте к 4 тыс. строк размер копипейстного куска и вернитесь к началу цикла :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Четверг, 28 Октябрь, 2010 20:26 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Peter Almazov писал(а):
Прибавьте к 4 тыс. строк размер копипейстного куска и вернитесь к началу цикла :)

Не больше 4 тыс. строк. Думаю меньше. Т.е. суммарно 8 килострок.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Четверг, 28 Октябрь, 2010 20:36 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4593
Откуда: Россия, Орёл
Alexey Veselovsky писал(а):
Вопрос -- что выбрать?
я бы выбрал большую определённость: хорошая документация = возможность разобраться и дорабатывать самому без проблем = зависимость только от себя
(припоминая поговорку: хочешь сделать хорошо --- сделай сам)
Alexey Veselovsky писал(а):
Не больше 4 тыс. строк. Думаю меньше. Т.е. суммарно 8 килострок.
особенно, учитывая объёмы


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Четверг, 28 Октябрь, 2010 20:50 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Евгений Темиргалеев писал(а):
Alexey Veselovsky писал(а):
Вопрос -- что выбрать?
я бы выбрал большую определённость: хорошая документация = возможность разобраться и дорабатывать самому без проблем = зависимость только от себя
(припоминая поговорку: хочешь сделать хорошо --- сделай сам)
Alexey Veselovsky писал(а):
Не больше 4 тыс. строк. Думаю меньше. Т.е. суммарно 8 килострок.
особенно, учитывая объёмы

Объемы, кстати, достаточно значительные. В переводе на объемы Си или Оерон-кода это где-то порядка 20 тыс. строк кода нужно будет дописать. Ну и потребуется проработать порядка 300 страниц всяких rfc.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Четверг, 28 Октябрь, 2010 21:58 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 552
Откуда: Москва
Какая у Вас производительность труда - сколько в среднем строк в день выдаете?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 08:08 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Peter Almazov писал(а):
Какая у Вас производительность труда - сколько в среднем строк в день выдаете?

Это очень и очень зависит от. Бывает и до 600 строк в день (java, реализация того, что сам придумал и продумал). А бывает что и ноль в неделю.

В этом случае нельзя сразу садиться кодить. Вначале нужно будет проштудировать rfc. Потом провести ряд экспериментов на предмет того насколько эти rfc соответствуют реальному миру. И вот уже опосля-я.. Ориентировочный объем rfc я привел выше.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 12:28 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 552
Откуда: Москва
Ноль в неделю - это знакомо :)
600 - круто.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 13:34 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Alexey Veselovsky писал(а):
Нужно также учесть, что возможно в дальнейшем могут потребоваться некий функционал который реализован в первой программа, а во второй нет. Скопипастить код из первой во вторую нельзя -- лицензионные ограничения. Т.е. придется видимо реализовывать самому, ежели таковая потребность возникнет. Характерное время возникновения таковой потребности -- где-то полгода.
А в "активно развивающейся" программе эта функциональность точно будет? Это я в том смысле, что уже сейчас известно, что вам может понадобиться и что будет в этой программе, но только имеется некотороя неопределённость в виде отсутствия отмашки от начальства? Просто как бы потом в этой "активной" программе для задейстования появившегося функционала не пришлось переписывать свои допилы, прекрасно работавшие уже полгода-год.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 14:38 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Valery Solovey писал(а):
Alexey Veselovsky писал(а):
Нужно также учесть, что возможно в дальнейшем могут потребоваться некий функционал который реализован в первой программа, а во второй нет. Скопипастить код из первой во вторую нельзя -- лицензионные ограничения. Т.е. придется видимо реализовывать самому, ежели таковая потребность возникнет. Характерное время возникновения таковой потребности -- где-то полгода.
А в "активно развивающейся" программе эта функциональность точно будет? Это я в том смысле, что уже сейчас известно, что вам может понадобиться и что будет в этой программе, но только имеется некотороя неопределённость в виде отсутствия отмашки от начальства? Просто как бы потом в этой "активной" программе для задейстования появившегося функционала не пришлось переписывать свои допилы, прекрасно работавшие уже полгода-год.

В данном случае начальство -- это пользователь. И этот функционал с некоторой вероятностью может таки понадобиться ему. Этот функционал не то что будет, он в той программе уже есть и работает.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 15:01 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Для определенности -- эти приложения, это rtmp-сервера. Ну, или, как в народе называют, flash-сервера. Сервер для flash приложения. (http://en.wikipedia.org/wiki/Real_Time_ ... g_Protocol http://ru.wikipedia.org/wiki/RTMP).

Кроме бизнес-логики и собственно rtmp на стороне сервера возможно нужно будет реализовать вещание видео. На вход серверу идет rtp либо rtsp либо rtmp. Он раздает это видео множеству подключенных клиентов по rtmp. Также возможно потребуется показывать уже записанное и уже хранящееся на диске видео. Соответственно нужна поддержка mp4, avi, mp3 и проч форматов-контейнеров.

rtp, rtsp, mp4, mpeg, mp3 -- реализованы в одном сервере и не реализованы в другом. И это может понадобиться с некоторой вероятностью.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 15:47 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Alexey Veselovsky писал(а):
Есть две программы...
Одна размером примерно в 25 тыс. строк кода и активно развивается, а другая 4 тыщи строк понятного кода и хорошо задокументирована (в т.ч. потроха), но труп (т.е. никем не пилится, сообщества нет, поддержки нет и т.п.). Вопрос -- что выбрать?
..
Вот сижу как буриданов осёл между этими двумя вариантами и рискую повторить его судьбу..
Разработчики второй программы уже переросли главную проблему,
а разработчики первой ещё и не увидели её(судя по масштабам кодостроительства, им это и не светит).

Alexey Veselovsky писал(а):
потребуется показывать уже записанное и уже хранящееся на диске видео. Соответственно нужна поддержка mp4, avi, mp3 и проч форматов-контейнеров.
В последнем Вы точно уверены? А если формат хранения максимально приблизить к формату вещания? Т.е. напрашивается вывод, что главная проблема решается явно не на уровне выбора из какой кучи копипастить.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 15:58 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Рэйлвэй Каген писал(а):
Alexey Veselovsky писал(а):
Есть две программы...
Одна размером примерно в 25 тыс. строк кода и активно развивается, а другая 4 тыщи строк понятного кода и хорошо задокументирована (в т.ч. потроха), но труп (т.е. никем не пилится, сообщества нет, поддержки нет и т.п.). Вопрос -- что выбрать?
..
Вот сижу как буриданов осёл между этими двумя вариантами и рискую повторить его судьбу..
Разработчики второй программы уже переросли главную проблему,
а разработчики первой ещё и не увидели её(судя по масштабам кодостроительства, им это и не светит).

А озвучьте, для определенности, Главную Проблему.

Рэйлвэй Каген писал(а):
Alexey Veselovsky писал(а):
потребуется показывать уже записанное и уже хранящееся на диске видео. Соответственно нужна поддержка mp4, avi, mp3 и проч форматов-контейнеров.
В последнем Вы точно уверены? А если формат хранения максимально приблизить к формату вещания? Т.е. напрашивается вывод, что главная проблема решается явно не на уровне выбора из какой кучи копипастить.

Про копипасту речи нет. Вопрос в том, на базе чего делать своё решение.
На счет форматов -- вот залил тебе пользователь на сервер файл в mp4, а другие хотят просмотреть то, что он залил. Либо хранить его as is, либо конвертировать. В обоих случаях нужно уметь mp4 формат. Это первый случай. Случай второй -- вот есть у нас сетевая камера. Она выдает скажем rtp поток. Или rtsp. Польователь зашел и хочет посмотреть что видно с этой камеры. Как тут быть не умея rtp и/или rtsp?

Другое дело что я не знаю точно понадобится это (именно эти варианты использования сервиса) или нет. А решать надо сейчас.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 16:15 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Alexey Veselovsky писал(а):
А озвучьте, для определенности, Главную Проблему.
формат хранения
Alexey Veselovsky писал(а):
Вопрос ещё в том, на базе чего делать своё решение.. Либо хранить его as is, либо конвертировать.
Вы практически ответили.. Вопрос в том, до какой глубины конвертировать. Соответственно прояснится нагрузка на софтину.
Alexey Veselovsky писал(а):
Как тут быть не умея rtp и/или rtsp?
это как раз нужно уметь лучше всего, раз уж Вы опираетесь на вещание в этих форматах.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 16:23 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Рэйлвэй Каген писал(а):
Alexey Veselovsky писал(а):
А озвучьте, для определенности, Главную Проблему.
формат хранения

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

Рэйлвэй Каген писал(а):
Alexey Veselovsky писал(а):
Вопрос ещё в том, на базе чего делать своё решение.. Либо хранить его as is, либо конвертировать.
Вы практически ответили.. Вопрос в том, до какой глубины конвертировать. Соответственно прояснится нагрузка на софтину.

Я ж говорю -- перосто перекладываение из одного контейнера в другой. О конвертации самих медиаданных речи не идет. Я ж написал поддержка mp4, avi а не h264, h261 и т.п.

Рэйлвэй Каген писал(а):
Alexey Veselovsky писал(а):
Как тут быть не умея rtp и/или rtsp?
это как раз нужно уметь лучше всего, раз уж Вы опираетесь на вещание в этих форматах.

Вещать в этих форматах никто собственно не (пока) собирается. В этих форматах оно может идти на вход сервера. Вещание идет в rtmp.
Это функционал может понадобиться, а может не понадобиться. Точный объем rfc описывающих эти форматы и протоколы вы можете посмотреть сами.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 16:55 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Как-то Вы на ходу меняете исходные..
Alexey Veselovsky писал(а):
возможно нужно будет реализовать вещание видео..
Alexey Veselovsky писал(а):
На вход серверу идет rtp либо rtsp либо rtmp. Он раздает это видео множеству подключенных клиентов по rtmp.
Alexey Veselovsky писал(а):
Либо хранить его as is, либо конвертировать.
А теперь "не хранить", "не конвертировать", "не вещать".. Но дело даже не в этом - какбэ нас не отстрелили за флейм :) .

1. Сама постановка вопроса "чьё решение допиливать" из-за незаложенного другими функционала не лежит в плоскости проектирования, особенно при отсутствии отмашки от начальства.
2. Вопрос о технической разнице между указанными конкретными реализациями неизбежно сведётся к анализу формата хранения сообразно Вашей задаче. Одно дело допиливать потроха, совсем другое - некий модуль расширения функциональности(не трогая базовые вещи).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 17:13 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Рэйлвэй Каген писал(а):
Как-то Вы на ходу меняете исходные..
Неа. Не меняю. Сейчас уточню.
Alexey Veselovsky писал(а):
возможно нужно будет реализовать вещание видео..

Да. Вещание по rtmp. (не путать с rtsp и rtp).
Alexey Veselovsky писал(а):
На вход серверу идет rtp либо rtsp либо rtmp. Он раздает это видео множеству подключенных клиентов по rtmp.

Да, на вход идет rtmp, rtp, rtsp. При этом rtmp -- точно. rtp и rtsp могут понадобиться, а могут не понадобится. Тот самый не однозначный функционал. о котором было сказано сразу в первом же сообщении.

Рэйлвэй Каген писал(а):
Alexey Veselovsky писал(а):
Либо хранить его as is, либо конвертировать.
А теперь "не хранить", "не конвертировать", "не вещать".. Но дело даже не в этом - какбэ нас не отстрелили за флейм :) .

Не вещать (а может и вещать) в rtp и rtsp, вещать в rtmp. Эти волшебные непонятные аббревиатуры, такие похожие и все начинающиеся на букву 'r' всё же сильно разные и это имеет значение :-)

Нужно будет хранить (читать или писать) в mp4, avi формате или нет -- также не известно. Возможно, что да.

Рэйлвэй Каген писал(а):
1. Сама постановка вопроса "чьё решение допиливать" из-за незаложенного другими функционала не лежит в плоскости проектирования, особенно при отсутствии отмашки от начальства.

Что-то тут второй раз уже упоминается некое мифическое начальство. Эмм.. Попытка переложить ответственность? ;-) Решение целиком на мне. Собственно обычная вилка -- тут допиливать проще, но нужно будет пилить существенно больше, а там допиливать сильно сложнее, но возможно не придется допиливать вообще, либо допилит кто-то другой, либо допил потребуется небольшой, с малой долей вероятности -- большой и геморройный. В первом мы контролируем и понимаем весь код, во втором нет.

Рэйлвэй Каген писал(а):
2. Вопрос о технической разнице между указанными конкретными реализациями неизбежно сведётся к анализу формата хранения сообразно Вашей задаче. Одно дело допиливать потроха, совсем другое - некий модуль расширения функциональности(не трогая базовые вещи).

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

В дальнейшем может потребоваться уметь понимать mp4, avi, rtp, rtsp. Просто потому, что расширение функционала решения может пойти в сторону расширения видов источников данных. Т.е. пользователь сможет залить видеофайл. Сможет подключить сетевую видеокамеру и т.п.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 17:34 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Нууу.. С такой "бородой" - только из собственного бизнес-модуля vlc батником пускать :). Правда есть сомнения по поводу наличия rtmp у vlc'шки. Да и архитектура у неё совсем дурная. Больше смахивает на бытовой ложковилконожик. Я не стал бы такое допиливать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 17:40 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Рэйлвэй Каген писал(а):
Нууу.. С такой "бородой" - только из собственного бизнес-модуля vlc батником пускать :). Правда есть сомнения по поводу наличия rtmp у vlc'шки. Да и архитектура у неё совсем дурная. Больше смахивает на бытовой ложковилконожик. Я не стал бы такое допиливать.

VLC вообще не вариант. Разве что прикручивать его сбоку, для конвертирования куда-то там. Это как-то слишком криво...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Типичная проблема выбора.
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 17:52 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Alexey Veselovsky писал(а):
там допиливать сильно сложнее, но возможно не придется допиливать вообще, либо допилит кто-то другой, либо допил потребуется небольшой, с малой долей вероятности -- большой и геморройный.
Честно говоря, это ближе к "сдохнет либо шах, либо ишак". По первому варианту ишак сдохнет точно. Вот такая эмпирика получается :)


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 25 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2020, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB