И что? В договор прописываются максимально широкие обязанности. Сисадмины тоже пишут код.
Бремя доказательства? Да пожалуйста, какие проблемы. Штат юристов легко предоставит свои аргументы в суде.
Именно. А у этих площадок так же есть владельцы — снимающие прибыль. А есть наемные работники, благодаря труду которых, эти площадки функцианируют. А еще есть момент, что в странах развитых, работники защищены гораздо лучше. Тут тебе и минимальная плата, тут тебе и рабочий день 8-ми часовой, тут тебе и отпуск… Так что выгоднее нанимать народ из бедных стран. Там и за еду работать готовы. Ну а продукт потреблять, конечно, будут страны развитые…
«Бизнес в России превращается в игру с нулевой суммой».
Рыночный капитализм — это всегда игра с нулевой суммой, что бы по этому поводу не фантазировали либертарианцы.
Вас возмущает, что капиталисты становятся ужасно жадными, когда речь идет о 650 млн долларов? Что за наивность?
Возьмите кредит на 100 тыс руб и попробуйте не вернуть.
Программист — это пролетарий 21-го века.
А капиталисты с века 19-го никак не изменились.
И если классический рабочий класс сумел за пару столетий выбить себе определенные права, что новый «пролетариат» не сделал по сути ничего. Перед его носом, как перед осликом, держат эту морковку, мол, и вы тоже сможете стать такими как мы, капиталисты, если будете прилежно на нас работать, как Бил Гейтс, ага. А пока подпишитесь в этом договорчике о полной передаче прав интеллектуальной собственности на все что бы вы ни изобрели/создали, хотя платить мы вам будем только за сисадминство (как в истории с Сысоевым и Рамблером).
На самом деле, работникам айти нужен профсоюз. И договор коллективный, в котором бы подобные статейки в контракте не имели возможности появится. Но либертарианцам эта идея ой как не нравится. Права наемных работников? Фу, фу, ужас.
Вот, совершенно правильный здравый взгляд на вопрос. Дело вовсе не в опен соурсе. Дело в правах на интеллектуальную собственность. Сысоев мог выпустить продукт и под закрытой лицензией. Что от этого бы поменялось?
Вся проблема в практике составления трудовых договоров в отношении интеллектуальной собственности возникающей во время работы сотрудника в компании.
Я вот программист. И я уверен многие коллеги сталкивались в договорами, где по сути сказано, что все что ты разработал во время работы в компании, вне зависимости когда ты это делал, по чьей инициативе, оплачивалась ли эта работа или нет, принадлежит компании.
Это широко распространенная практика. И привлечь по этой статье могут потом любого.
Лукавая, лживая статья. Яндекс за все хорошее против всего плохого?
Давайте предоставьте свой типовой договор с сотрудниками и как там описывается вопрос разделения прав на интеллектуальную собственность. Покажите на вашем примере, чем вы принципиально в этом вопросе отличаетесь от рамблера.
А то такие все пушистые на словах. А в договоре у вас что???
Вот, например, сотрудник ваш, во время работы у вас, из личного интереса разработает по собственной инициативе некий программный продукт. А после уйдет из компании, организует свою, зарегистрирует на нее продукт а после продаст за пол миллиарда долларов американцам. Вот, я думаю, что запоют тогда юристы, финансисты и директора яндекса? Да кто вам позволит упускать прибыль??? Да еще в таком объеме.
Так что хватит лицемерия — типовой договор в студию! А мы здесь рассмотрим, что у вас и как.
И еще, в продолжение сказанного выше, хотелось бы предложить Highload++ и «програмным комитетам» разработать «золотой стандарт» трудового договора компании и программиста в части разделения прав интеллектуальной собственности. Так, чтобы подобный договор защитил программистов от возможных наездов в будущем. И желательно, чтобы типовые договора уважающих себя компаний проходили сертификацию на соответствие такому стандарту. Так, чтобы программист знал, нанимается ли он в «хорошую» компанию, или в какашку. Потому что самому разбираться в юридическом крючкотворстве и соответствующей правоприменительной практике программисту далеко не всегда под силу. И даже не каждый юрист сможет грамотно помочь. А те, что берутся, всегда оставляют для себя лазейку, мол, если что не так, мы ответственности не несем. Ну, юристы, они такие ребята ;-).
На мой взгляд проблема вообще в порочной практике, когда в контракте закрепляется право интеллектуальной собственности компании на все, что разработал человек, пока работал в компании. Даже если он это делал не по заданию компании.
Сысоев, насколько я понял, работал в Рамблере сисадмином, когда писал Nginx. Что дало повод для последующих претензий со стороны Рамблера.
У меня вот есть конкретное предложение ко всем известным людям из статьи и высоким начальникам из подписавшихся здесь в защиту Сысоева: расскажите/покажите, как вы в вашей компании регулируете этот вопрос. На примерах договоров.
А то вот по моей практике программиста, каждый работодатель пытается впихнуть нечто подобное в трудовой договор. А когда начинаешь спрашивать, идут отговорки, мол, это просто формальность, это юротдел так придумал договор и т.д. Вот теперь и видим, чем эти «просто формальности» могут обернуться, когда написанный по личной инициативе продукт продается за пол миллиарда долларов.
Вообщем, бороться надо в принципе с подобной практикой закрепления интеллектуальных прав на работу программистов. Чтобы суды легко принимали решения о неправомерности уже самих подобных статей в трудовых договорах.
"… рёберные кубики перемещаются в направлении первого поворота, при этом два кубика как бы поворачиваются вдоль соответствующих граней (вокруг их оси), а третий также поворачивается, но при этом переворачивается. Переворачивается тот кубик, который перемещается между верхними рёбрами, в случае обычного (не перевёрнутого) Y-движения..." — мозк начинает закипать :-).
"… если выполнить три раза по два движения, то кубики повернутся три раза и в результате вернутся в исходное состояние..."
А если два по три? А если шесть по одному?
«если выполнить Y-движение шесть раз подряд, то состояние кубика вернётся в изначальное»
Што? Так чем отличается «три по два» от «шесть раз подряд»?
Все, пошел за отверткой. Шоб тебе, автор, так ТЗ писали :-).
У меня супруга, если останавливаемся в мотеле, имеет привычку закупаться продуктами как дома. А потом по факту едим в ресторанах и кафе. В результе регулярно оставляем нераскупоренные продуты: молоко, масло, оливки и т.д. в том числе и вино бывает ;-).
Я предпочитаю верить, что их не выбрасывают, а оставляют следующим гостям.
«В паре квартир при заселении на столе ждала бутылка хорошего вина».
Ага. И деньги крупными купюрами в холодильнике :-).
Я не против экономии, но иногда рассказы «бюджетников» улыбают.
О, да, полиция только спит и видит, как бы заняться разборками типа «на фоточке квартира выглядела иначе».
Обратите внимание, что одна из потерпевших — вообще юрист, которая, по ее собственным словам, любит разбираться с подобными случаями. И даже у нее результат не впечатляет — после кучи потраченного времени, она вернула деньги. Каждый час юриста стоит трехзначную сумму как минимум. Смысл заниматься, если в конце концов потратишь больше. Судиться простому человеку с компанией с капитализацией в миллиарды и большим штатом юристов? Ну, удачи.
Тут одна надежда. Что за эту ситуацию ухватятся конкуренты — возможно какие-то сети отелей и т.п. История стала публичной. И тогда могут измениться процедуры по валидации жилья и арендаторов.
А какие еще варианты рассматривались и почему именно Швейцария? Я вот знаю, Ирландия очень популярна для регистрации IT компаний с прицелом на рынок ЕС. Этот вариант чем не подошел?
Там фишка в том, что эти компании для подтверждения счета клиента переводят на них небольшую сумму. Т.о. создав несколько тысяч клиентов с общим счетом можно аккумулировать приходящие деньги и снять.
У меня вот такая ситуация. Когда ты полностью нагружен, а тебя хотят подгрузить еще чем-то срочным, начальство говорит, мол, мы все понимаем, и дадим тебе в помощь сотрудника (типа он поможет тебе с твоей основной задачей). Как обычно, незанятым «помощником», оказывается не хороший специалист — они все так же загружены, а местный «балабол», которому ничего серьезного не поручают, вот его и пытаются хоть для чего-то приспособить. Скажу честно, мне все гораздо проще сделать самому, чем долго объяснять этому челу детали (а начинать придется сильно из далека), потом он долго будет изображать сильную занятость, а в конце концов предъявит нечто малопригодное и все равно придется скорее всего переписывать с чистого экрана.
Вот подскажите, как в таких ситуациях поступать?
Я кажется начинаю понимать логику. Вы ходите контролировать не только свои процессы, но, и внутренние процессы ваших поставщиков, т.е., условно говоря, как ваши топливозаправщики взаимодействуют с банком (протокол этого взаимодействия, используемый софт, банк). А для достижения цели, вы вводите единую среду, которая позволяет вам все это видеть. В принципе, преимущества понятны — это преимущества плановой организации.
По сути, вы вводите ту же самую централизацию управления и мониторинга процессов, только в качестве среды хранения и исполнения используется блокчейн. На самом деле, ничего нового. В СССР в таком случае все транзакции проходили бы в одном «министерском» ВЦ, четко по единым процедурам, нормативам и т.п.
Проблема в том, что в условиях рынка, такая система не слишком хорошо работает. Я участвовал в подобных проектах, и могу по опыту сказать результаты.
Итак, вы предпишете как ваши подрядчики должны организовать свою работу, завязав все в единый процесс детально описанный в виде смарт контрактов.
В результате, получится следующее:
1. Вы потеряете гибкость в выборе поставщиков из-за высоких требований по вхождению. Т.е. грубо говоря, если в случае с АПИ, новому поставщику для взаимодействия с вами необходимо будет внедрить лишь ваш АПИ, без изменения внутренних процессов и процессов взаимодействия с их банком, поставщиками и т.д., то при вашем подходе, им придется полностью переделывать взаимодействие с банком, с водителями и т.д.
2. Навязывание одинаковых процессов всем поставщикам. А у каждого могут быть свои особенности, ну, вот связанные с регионом, например. И т.о. единые процессы могут быть неоптимальны. В случае с АПИ вы вообще эти проблемы не чувствуете — каждый региональный поставщик организует работу наиболее оптимально для своих условий.
В результате, вас будут заправлять дольше и дороже, чем ваших конкурентов.
На нашем случае, вся идея выродилась в трех крупных поставщиков (из десятков возможных), которые очень быстро поделили делянки и стали выставлять завышенные условия. При том что вокруг куча боле мелких и дешевых, работающих быстрее и качественнее, но они не готовы переделывать свои внутренние системы и процессы под условия заказчика, и по причине стоимости и по той причине, что в этих «ноу хау» организации работы заключаются их конкурентные преимущества.
А дальше пошел следующий круг ада. Большие поставщики сообразили, что им выгоднее перепродавать контракты мелким контакторам (естественно без навязывания им внедрения всех процессов и айти архитектуры), а самим просто снимать маржу на том, что у них есть интерфейс разработанный согласно вашим требованиям (взаимодействие через блокчейн и т.д.).
А дальше, в кругу третьем. Посредники, уволившие всех ребят в оранжевых жилетах, и ставшие исключительно менеджерами, лойерами и финансистами, очень жадные ребята. В результате мелкие фирмы, фактически выполняющие всю работу, стали хронически недофинансироваться, что привело к серьезному падению качества услуг. Опытные работники стали уходить. Обновление оборудования, тех процессов не проводилось.
А дальше наступает катарсис. Если кратко, головное предприятие решает похерить всю эту пирамиду, сделать открытый, легкий и понятный апи, который качественно снизит порог вхождения для поставщиков и позволит создать конкурентную среду. И боже упаси лезть во внутренние дела поставщиков :-).
А для кого нужна эта «единая информационная картина»?
Банку вряд ли интересно знать детали процесса заправки. Более того, ему и не нужно этого знать, чтобы обеспечить гибкость изменения процессов, которые банк непосредственно не касаются. То же и с заправщиком. А у s7 и так все есть, потому что там происходит оркестрация, и точно известно сколько запросили топлива, во сколько подтвердили, когда оплатили и т.д.
Кроме того, вы же сами пишите, что стоит задача четко ограничить доступ к данным. Так не лучший ли способ это сделать, скрыв внутренние детали за API и именно на этом рубеже контролировать, какие данные отдаются и кому? Если использовать предложенную выше аналогию с распределенной ДБ, то как раз к блокчейну больше вопросов по доступу к данным.
Понимаете, когда весь процесс не раскрыт, на общих словах трудно представить. Вот взять схему с топливозаправщиками. Этот процесс начинается у вас, где-то в системе через которую ваш персонал запрашивает заправку. Дальше, есть поставщик. У него, наверное, есть апи, куда ваша система посылает запрос, а он отвечает ценой (упрощенно). Потом, вы подтверждаете заявку — он подтверждает выполнение. Еще есть банк. У которого свой апи. От банка вам нужно две функции: зарезервировать деньги и осуществить перевод. Вот собственно и все. И зачем здесь блокчейн, можно пожалуйста объяснить?
Так это стандартная вообще ситуация. При чем тут БД, если линия разграничения — АПИ? Просто все важные транзакции подписываются. При каких-то вопросах, всегда можно поднять подписанный запрос или подтверждение о получении.
Агенту нужно сделать вручную перевод через банк-клиент. Это медленно и полуавтоматизированно.
Ну, я не могу с этим согласиться. У банка есть АПИ. И переводы в банке через этот апи осуществляются если не мгновенно, то уж во всяком случае, быстрее чем через блокчейн в том же банке.
Насчет подтверждения от «двух и более сторон», я вот не вижу кейса в данном случае. Множество ролей не значит автоматически множества сценариев где требуется такое подтверждение. Я так полагаю, для каждого процесса в их бизнесе уже четко определен владелец. И он будет вести процесс через транзакции и отвечать за прохождение.
Гхм. Я даже затрудняюсь комментировать мысли насчет сертификатов, потому что не понятно, что конкретно не устраивает. Вы можете использовать тот УЦ, который подходит для вашей задачи. Вплоть до использования законодательно предписанных УЦ, криптографических алгоритмов и сертифицированного софта.
Конкретно у S7 уже есть вся необходимая инфраструктура и процедуры, которые они используют для своего агентского АПИ.
Насчет абстрагироваться от блокчейна в данном случае вообще не понятно. Распределенная БД? А зачем S7 «распределять» свою БД? Это сразу серьезнейшим образом усложняет решение и создает просто массу проблем на пустом месте.
Короче говоря, возвращаясь к статье, хочется сказать автору следующее.
Без более развернутой информации о том, какую проблему вы пытаетесь решить, какие варианты рассматривались, почему выбрали именно этот, совершенно не понятно, зачем блокчейн вообще нужен в вашей архитектуре.
В статье по этому поводу лишь два утверждения о том что использование АПИ ведет к
1. "централизации сервисов, через которые идет взаимодействие". И что? Это плохо? Чем? (не вообще, а в рамках конкретной задачи).
2. "к росту количества и типов интеграций и усложнению информационного ландшафта организаций". Причем, под этим понимается сложность АПИ. В замен предлагается перенести ту же самую «сложность» в блокчейн и завести там множество контрактов для поддержки тех же сценариев. Кроме того, АПИ все же придется создать, причем на двух уровнях. Не понятно.
Бремя доказательства? Да пожалуйста, какие проблемы. Штат юристов легко предоставит свои аргументы в суде.
Рыночный капитализм — это всегда игра с нулевой суммой, что бы по этому поводу не фантазировали либертарианцы.
Вас возмущает, что капиталисты становятся ужасно жадными, когда речь идет о 650 млн долларов? Что за наивность?
Возьмите кредит на 100 тыс руб и попробуйте не вернуть.
Программист — это пролетарий 21-го века.
А капиталисты с века 19-го никак не изменились.
И если классический рабочий класс сумел за пару столетий выбить себе определенные права, что новый «пролетариат» не сделал по сути ничего. Перед его носом, как перед осликом, держат эту морковку, мол, и вы тоже сможете стать такими как мы, капиталисты, если будете прилежно на нас работать, как Бил Гейтс, ага. А пока подпишитесь в этом договорчике о полной передаче прав интеллектуальной собственности на все что бы вы ни изобрели/создали, хотя платить мы вам будем только за сисадминство (как в истории с Сысоевым и Рамблером).
На самом деле, работникам айти нужен профсоюз. И договор коллективный, в котором бы подобные статейки в контракте не имели возможности появится. Но либертарианцам эта идея ой как не нравится. Права наемных работников? Фу, фу, ужас.
Вся проблема в практике составления трудовых договоров в отношении интеллектуальной собственности возникающей во время работы сотрудника в компании.
Я вот программист. И я уверен многие коллеги сталкивались в договорами, где по сути сказано, что все что ты разработал во время работы в компании, вне зависимости когда ты это делал, по чьей инициативе, оплачивалась ли эта работа или нет, принадлежит компании.
Это широко распространенная практика. И привлечь по этой статье могут потом любого.
Давайте предоставьте свой типовой договор с сотрудниками и как там описывается вопрос разделения прав на интеллектуальную собственность. Покажите на вашем примере, чем вы принципиально в этом вопросе отличаетесь от рамблера.
А то такие все пушистые на словах. А в договоре у вас что???
Вот, например, сотрудник ваш, во время работы у вас, из личного интереса разработает по собственной инициативе некий программный продукт. А после уйдет из компании, организует свою, зарегистрирует на нее продукт а после продаст за пол миллиарда долларов американцам. Вот, я думаю, что запоют тогда юристы, финансисты и директора яндекса? Да кто вам позволит упускать прибыль??? Да еще в таком объеме.
Так что хватит лицемерия — типовой договор в студию! А мы здесь рассмотрим, что у вас и как.
Сысоев, насколько я понял, работал в Рамблере сисадмином, когда писал Nginx. Что дало повод для последующих претензий со стороны Рамблера.
У меня вот есть конкретное предложение ко всем известным людям из статьи и высоким начальникам из подписавшихся здесь в защиту Сысоева: расскажите/покажите, как вы в вашей компании регулируете этот вопрос. На примерах договоров.
А то вот по моей практике программиста, каждый работодатель пытается впихнуть нечто подобное в трудовой договор. А когда начинаешь спрашивать, идут отговорки, мол, это просто формальность, это юротдел так придумал договор и т.д. Вот теперь и видим, чем эти «просто формальности» могут обернуться, когда написанный по личной инициативе продукт продается за пол миллиарда долларов.
Вообщем, бороться надо в принципе с подобной практикой закрепления интеллектуальных прав на работу программистов. Чтобы суды легко принимали решения о неправомерности уже самих подобных статей в трудовых договорах.
"… если выполнить три раза по два движения, то кубики повернутся три раза и в результате вернутся в исходное состояние..."
А если два по три? А если шесть по одному?
«если выполнить Y-движение шесть раз подряд, то состояние кубика вернётся в изначальное»
Што? Так чем отличается «три по два» от «шесть раз подряд»?
Все, пошел за отверткой. Шоб тебе, автор, так ТЗ писали :-).
Я предпочитаю верить, что их не выбрасывают, а оставляют следующим гостям.
Ага. И деньги крупными купюрами в холодильнике :-).
Я не против экономии, но иногда рассказы «бюджетников» улыбают.
Обратите внимание, что одна из потерпевших — вообще юрист, которая, по ее собственным словам, любит разбираться с подобными случаями. И даже у нее результат не впечатляет — после кучи потраченного времени, она вернула деньги. Каждый час юриста стоит трехзначную сумму как минимум. Смысл заниматься, если в конце концов потратишь больше. Судиться простому человеку с компанией с капитализацией в миллиарды и большим штатом юристов? Ну, удачи.
Тут одна надежда. Что за эту ситуацию ухватятся конкуренты — возможно какие-то сети отелей и т.п. История стала публичной. И тогда могут измениться процедуры по валидации жилья и арендаторов.
Вот подскажите, как в таких ситуациях поступать?
По сути, вы вводите ту же самую централизацию управления и мониторинга процессов, только в качестве среды хранения и исполнения используется блокчейн. На самом деле, ничего нового. В СССР в таком случае все транзакции проходили бы в одном «министерском» ВЦ, четко по единым процедурам, нормативам и т.п.
Проблема в том, что в условиях рынка, такая система не слишком хорошо работает. Я участвовал в подобных проектах, и могу по опыту сказать результаты.
Итак, вы предпишете как ваши подрядчики должны организовать свою работу, завязав все в единый процесс детально описанный в виде смарт контрактов.
В результате, получится следующее:
1. Вы потеряете гибкость в выборе поставщиков из-за высоких требований по вхождению. Т.е. грубо говоря, если в случае с АПИ, новому поставщику для взаимодействия с вами необходимо будет внедрить лишь ваш АПИ, без изменения внутренних процессов и процессов взаимодействия с их банком, поставщиками и т.д., то при вашем подходе, им придется полностью переделывать взаимодействие с банком, с водителями и т.д.
2. Навязывание одинаковых процессов всем поставщикам. А у каждого могут быть свои особенности, ну, вот связанные с регионом, например. И т.о. единые процессы могут быть неоптимальны. В случае с АПИ вы вообще эти проблемы не чувствуете — каждый региональный поставщик организует работу наиболее оптимально для своих условий.
В результате, вас будут заправлять дольше и дороже, чем ваших конкурентов.
На нашем случае, вся идея выродилась в трех крупных поставщиков (из десятков возможных), которые очень быстро поделили делянки и стали выставлять завышенные условия. При том что вокруг куча боле мелких и дешевых, работающих быстрее и качественнее, но они не готовы переделывать свои внутренние системы и процессы под условия заказчика, и по причине стоимости и по той причине, что в этих «ноу хау» организации работы заключаются их конкурентные преимущества.
А дальше пошел следующий круг ада. Большие поставщики сообразили, что им выгоднее перепродавать контракты мелким контакторам (естественно без навязывания им внедрения всех процессов и айти архитектуры), а самим просто снимать маржу на том, что у них есть интерфейс разработанный согласно вашим требованиям (взаимодействие через блокчейн и т.д.).
А дальше, в кругу третьем. Посредники, уволившие всех ребят в оранжевых жилетах, и ставшие исключительно менеджерами, лойерами и финансистами, очень жадные ребята. В результате мелкие фирмы, фактически выполняющие всю работу, стали хронически недофинансироваться, что привело к серьезному падению качества услуг. Опытные работники стали уходить. Обновление оборудования, тех процессов не проводилось.
А дальше наступает катарсис. Если кратко, головное предприятие решает похерить всю эту пирамиду, сделать открытый, легкий и понятный апи, который качественно снизит порог вхождения для поставщиков и позволит создать конкурентную среду. И боже упаси лезть во внутренние дела поставщиков :-).
Банку вряд ли интересно знать детали процесса заправки. Более того, ему и не нужно этого знать, чтобы обеспечить гибкость изменения процессов, которые банк непосредственно не касаются. То же и с заправщиком. А у s7 и так все есть, потому что там происходит оркестрация, и точно известно сколько запросили топлива, во сколько подтвердили, когда оплатили и т.д.
Кроме того, вы же сами пишите, что стоит задача четко ограничить доступ к данным. Так не лучший ли способ это сделать, скрыв внутренние детали за API и именно на этом рубеже контролировать, какие данные отдаются и кому? Если использовать предложенную выше аналогию с распределенной ДБ, то как раз к блокчейну больше вопросов по доступу к данным.
Ну, я не могу с этим согласиться. У банка есть АПИ. И переводы в банке через этот апи осуществляются если не мгновенно, то уж во всяком случае, быстрее чем через блокчейн в том же банке.
Насчет подтверждения от «двух и более сторон», я вот не вижу кейса в данном случае. Множество ролей не значит автоматически множества сценариев где требуется такое подтверждение. Я так полагаю, для каждого процесса в их бизнесе уже четко определен владелец. И он будет вести процесс через транзакции и отвечать за прохождение.
Конкретно у S7 уже есть вся необходимая инфраструктура и процедуры, которые они используют для своего агентского АПИ.
Насчет абстрагироваться от блокчейна в данном случае вообще не понятно. Распределенная БД? А зачем S7 «распределять» свою БД? Это сразу серьезнейшим образом усложняет решение и создает просто массу проблем на пустом месте.
Короче говоря, возвращаясь к статье, хочется сказать автору следующее.
Без более развернутой информации о том, какую проблему вы пытаетесь решить, какие варианты рассматривались, почему выбрали именно этот, совершенно не понятно, зачем блокчейн вообще нужен в вашей архитектуре.
В статье по этому поводу лишь два утверждения о том что использование АПИ ведет к
1. "централизации сервисов, через которые идет взаимодействие". И что? Это плохо? Чем? (не вообще, а в рамках конкретной задачи).
2. "к росту количества и типов интеграций и усложнению информационного ландшафта организаций". Причем, под этим понимается сложность АПИ. В замен предлагается перенести ту же самую «сложность» в блокчейн и завести там множество контрактов для поддержки тех же сценариев. Кроме того, АПИ все же придется создать, причем на двух уровнях. Не понятно.