Re: Анонсы докладов 3 -й конференции по Firebird
Hello, Vadim! Vadim Mescheryakov wrote: А кто занимается сертификацией? Где посмотреть что и как? х.з. пробовал искать, но видимо, что-то не то ищу. P.S. У меня ощущение сложилось, что этот закон (ФЗ-153) нарушают 100% предприятий вполне возможно. у меня пока нет времени и сил прочитать этот закон от начала до конца чтобы понять, что вообще надо делать, в каких случаях и как надо сертифицироваться. Вернее, я его просматривал, и даже делал какие-то комменты, но за давностью уже все забыл. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Анонсы докладов 3 -й конференции по Firebird
Hello, Vadim! Vadim Mescheryakov wrote: ага. Это типа как те, кому надо соответствие ФЗ 153, о персональных данных. Т.е. как бы все хотят чтобы ФБ соответствовал, но никто не хочет ни копейки вложить в сертификацию. А какова цена вопроса? Сколько стоит сертификация? когда считал, было (и люди говорили) что минимум в районе 70-100к баксов. Это про гос-сертификацию по безопасности. И это не только деньги заплатил, и готово. Там много бумажной и организационной работы. Т.е. на сертификацию надо сдавать уже все готовое в соответствии с требованиями. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Анонсы докладов 3 -й конференции по Firebird
Hello, Vlad! Khorsun Vlad wrote: Если им это надо, то можешь поверить что и многим другим это надо. ГДЕ ЭТИ МНОГИЕ ДРУГИЕ ? И какого чёрта они ничего не делают, раз им ТАК СИЛЬНО это всё надо ? ага. Это типа как те, кому надо соответствие ФЗ 153, о персональных данных. Т.е. как бы все хотят чтобы ФБ соответствовал, но никто не хочет ни копейки вложить в сертификацию. А если вдруг например РедСофт начнет продавать сертифицированное решение, то эти все будут делать круглые глаза - как же так, почему за бесплатный сервер хотят столько бабла? p.s. извините, навеяло. просто какой-то натуральный ступор мозга у людей. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Анонсы докладов 3 -й конференции по Firebird
Sergey Mereutsa wrote: Так вот. Асинхронность, скажу я вам, штука зело вкусная, ежели её применять правильно. Особенно, когда у тебя работа с девайсом, у которого на борту 4 войсовых процессора и 30 войсовых каналов, которые ты в цикле опрашиваешь и вся работа с которыми - это работа с событиями на этих каналах. Но - как же без этого - есть у неё одна бааальшая ж%па при работе в многопоточной среде - в виде кошмара синхронизации тредов, запутанности и непонятности для простого человеческого процесса мышления. Начал за здравие, кончил за упокой. Асинхронность ввода вывода как раз позволяет уменьшить количество потоков и избавится от кошмарной синхронизации. Было: первый поток работает с железом, второй работает в БД. Стало: один поток работает и с железом и с БД. rtfm event-driven programing Минус в том, что в таком подходе усложняется код из за необходимости мыслить в терминах теории конечных автоматов и сложности с декомпозицией. А без многопоточности в эпоху мультиядерности оно нафиг никому не впилось. Это ты суперсервер так ловко подколол ? :)
Re: Анонсы докладов 3 -й конференции по Firebird
Khorsun Vlad wrote: Ну написать клиента на какую либо платформу. Каких платформ тебе не хватает ? Где *масса* применений ? Как ты думаешь, почему ява и нет клиенты не хотят использовать gds32.dll и ходят напрямую по сокетам? Почему? Зачем им этот секс? Сейчас эти клиенты на птичьих правах т.к. используют реверс-инженеринг недокументирванного протокола. А пользуют эти клиенты тысячи. Вот тебе и ответ на вопрос о количестве заинтересованных лиц. Если им это надо, то можешь поверить что и многим другим это надо. Да ну? В существующее api асинхронные возможности встроить практически невозможно, не перелопатив его всего. Конечно, лучше писать новый велосипед, не вникая в старый. Тут уже плакались что старое API не позволяет ввести длинные идентификаторы для объектов в БД. Наверняка аналогичный косяк кстати может всплыть и на уровне протокола. Совместимость со старыми клиентами никто не отменял. Клянёшься? А то тут уже намудрили, когда переход от F1.0 и выше происходит с большим скрипом из за проблем с обратной совместимостью. Потом, хоп, скажут, что для работы с FB X.Y клиент от FB 1.0 уже не прокатит и нужно обновить клиента.
Re[2]: Анонсы докладов 3-й конференции по Firebird
Привет! Начал за здравие, кончил за упокой. Асинхронность ввода вывода как раз позволяет уменьшить количество потоков и избавится от кошмарной синхронизации. Было: первый поток работает с железом, второй работает в БД. Стало: один поток работает и с железом и с БД. rtfm event-driven programing Это у тебя всё в диск упирается, а у меня куча логики в БД - соответственно, мне асинхронность нафиг не нужна :) Минус в том, что в таком подходе усложняется код из за необходимости мыслить в терминах теории конечных автоматов и сложности с декомпозицией. Вот и я о том же. Асинхронность хороша, когда у тебя нет кучи ядер. А без многопоточности в эпоху мультиядерности оно нафиг никому не впилось. Это ты суперсервер так ловко подколол ? :) Я супер в его нынешнем виде не использую, бо воне не распараллеливаеццо. А вот правильный супер - очень даже буду. :) З.Ы. Если кому-то интересно моё мнение - то я считаю, что в крайнем случае можно реализовать HTTP-обёртку рядом со своим собственным демоном и делать всё, что душе заблагорассудится. Но если очень сильно припечёт - то можно и свой libfbclient написать. С блэкджеком и далее по тексту. -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Анонсы докладов 3 -й конференции по Firebird
Игорь Горбонос wrote: И чесно говоря я не понимаю, почему нельзя сделать для себя модуль, который будет асинхронно выполняить запросы к БД, если есть такая необходимость? И как будет выглядеть этот модуль? Который должен быть универсальным. Он не может вернуть курсор в другой поток, т. к. при разборе результата даже простой isc_fetch должен выполнится асинхронно, т.к. может заброкироваться надолго. В результате бизнес-логику надо размазывать по двум потоком - основным и потоком работающим с БД.
Re: Анонсы докладов 3 -й конференции по Firebird
Khorsun Vlad wrote: Я же вижу ситуацию так - *он хочет* непонятно чего и зачем, Применений масса. Я уже давно плачу что необходимо асинхронное взаимодействие с сервером. Чтобы поток не тупо ждал ответа сервера в блокирующем режиме, а мог в это время заниматься другими делами. Допиливать текущее api для этого уже практически невозможно - пациент уже мёртв. Проще всего, имея сокетный протокол, работать с сокетами асинхронно, что технически уже давно стало нормой. PS Ещё раз - я не против создания описания текущего протокола. Вот примерно это я и хотел услышать. Но я не хочу этим заниматься, в том числе и потому, что это не нужно не только мне, но и никому другому. Если кто-то хочет этим заняться - буду рад помочь. Кто сказал что лично тебе этим надо заниматься сию минуту? Этим мог бы заняться и кто другой, хоть и я. Но при условии что этот документ будет принят в качестве стандарта и протокол будет поддерживаться вплоть до конца Вселенной.
Re[2]: Анонсы докладов 3-й конференции по Firebird
Привет! Народ тупо не понимает что это такое. В оракле кстати есть асинхронность в API. Паззаны, скузе муа, что вмешиваюсь в вашу дуэль на канделябрах, но позвольте высказать своё мнение, сугубо как программера. Довелось мне работать с асинхронным API в бытность программинга IVR приложений для телекоммуникаций (для плат Dialogic, которых Интел купил в своё время). Так вот. Асинхронность, скажу я вам, штука зело вкусная, ежели её применять правильно. Особенно, когда у тебя работа с девайсом, у которого на борту 4 войсовых процессора и 30 войсовых каналов, которые ты в цикле опрашиваешь и вся работа с которыми - это работа с событиями на этих каналах. Но - как же без этого - есть у неё одна бааальшая ж%па при работе в многопоточной среде - в виде кошмара синхронизации тредов, запутанности и непонятности для простого человеческого процесса мышления. А без многопоточности в эпоху мультиядерности оно нафиг никому не впилось. Вот так вот, мои 0.02MDL как любят выражаться некоторые в кузнице :) -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Анонсы докладов 3 -й конференции по Firebird
Khorsun Vlad wrote: Применений масса. Да ну ? Где ? Ну написать клиента на какую либо платформу. Я уже давно плачу что необходимо асинхронное взаимодействие с сервером. Кому нужно ? Почему ты один об этом плачешь ? Меня можно считать за десятерых :) Не надо идти на поводу у большенства. В результате имеем попсу с стиле МС и до сих пор не работающий SMP в супере. Народ тупо не понимает что это такое. В оракле кстати есть асинхронность в API. Чтобы поток не тупо ждал ответа сервера в блокирующем режиме, а мог в это время заниматься другими делами. Почему нельзя это реализовать уровнем выше, в DAL ? А кто этот DAL писать/проектировать будет? Для каждого проекта новый? Надо тупо асинхронно послать sql запрос и получить ответ. Сейчас, да, есть костыли в виде выноса взаимодействия с БД в отдельный поток, но это даёт много проблем и ограничений. Допиливать текущее api для этого уже практически невозможно - пациент уже мёртв. Несколько смелое утверждение, не имеющее под собой ни какого обоснования. Да ну? В существующее api асинхронные возможности встроить практически невозможно, не перелопатив его всего. Но при условии что этот документ будет принят в качестве стандарта и протокол будет поддерживаться вплоть до конца Вселенной. Это ты не по адресу. Пиши письма в IEEE, SQL Standard Commitee, EC, UN, etc... Стандарта в среде FB, канонизации. Неужели не понятно о чём речь?
Re: Анонсы докладов 3 -й конференции по Firebird
Khorsun Vlad wrote: И где тут свой транспорт ??? Про транспорт это другая, более далёкая, хотелка. Это годится только для приложения вроде hello firebird. Это только пример, реализовав который можно постепенно доработать функционал до желаемого уровня. Описание всех пакетов и их потрохов живут в protocol + xdr. Какие пакеты требуются для каких АПИ функций - см. interface. Дык я знаю где они живут. Вопрос в том, чтобы специфицировать это на уровне документов аля RFC. Имеющему глаза не нужно ничего другого, кроме этих файлов. Это задаёт слишком высокий ценз для желающих достучаться до FB.
Re: Анонсы докладов 3 -й конференции по Firebird
Khorsun Vlad wrote: Про транспорт это другая, более далёкая, хотелка. Так ты же с неё начал ? В изначальном сообщении я высказал две мысли: 1) Доступ к серверу по сокетам. 2) Возможность указывать свой транспорт для gds32.dll Нельзя ли в одной теме обсуждать ОДНУ вещь ? Ну уж если очень хочется, то можно. Это только пример, реализовав который можно постепенно доработать функционал до желаемого уровня. И называться он будет - новое АПИ. И для текущего набора типов пакетов ты не сделаешь ничего кардинально другого, ибо оно взаимосвязано. Это само собой. Просто это даст новое качество в портировании. Одно дело пытаться портировать устаревший gds32.dll куда попало. А совсем другое дело имплиментировать задокументированный сетевой протокол. На землю спустись :) И посмотри таки на protocol.cpp *открытыми* глазами. Это не наши методы. Точнее не методы для промышленного ПО. Каждый кто хочет использовать это не должен ковыряться в исходниках. Если оно тебе вообще надо. Мне нада не protocol.cpp, а стандартизация того что там написано. Чуешь разницу?
Re: Анонсы докладов 3 -й конференции по Firebird
Dmitri Kuzmenko wrote: возьми исходники клиента .Net или JayBird и посмотри. Дык первого я и смотрел. Не в о том речь. Речь о написании клиентов на всяких экзотических платформах коих сейчас расплодилось немерянно. Ковырять левые сорцы юзающие недокументированные фичи - это не продуктивно. Идея в том, чтобы раз и навсегда задокументировать протокол обмена, чтобы заинтересованные разработчики могли легко достучаться до сервера, обладая только TCP стеком.
Re: Анонсы докладов 3 -й конференции по Firebird
так и надо делать для тонких клиентов. 30.09.2010 14:29, Yurij wrote: On Sep 30, 9:52 am, Alexey Popova...@novgorod.net wrote: возьми исходники клиента .Net или JayBird и посмотри. Дык первого я и смотрел. Не в о том речь. Речь о написании клиентов на всяких экзотических платформах коих сейчас расплодилось немерянно. Ковырять левые сорцы юзающие недокументированные фичи - это не продуктивно. Идея в том, чтобы раз и навсегда задокументировать протокол обмена, чтобы заинтересованные разработчики могли легко достучаться до сервера, обладаятолько TCP стеком. Имхо, проще рядом с FB поставить веб-сервис и завернуть всю бизнес- логику в него, уж по HTTP с экзотических платформ ходить намного проще, нежели реализовывать stateful протокол на всех мыслимых и немыслимых вариациях железа и ОС.
Re: Анонсы докладов 3 -й конференции по Firebird
Yurij wrote: Имхо, проще рядом с FB поставить веб-сервис и завернуть всю бизнес- логику в него, уж по HTTP с экзотических платформ ходить намного проще, нежели реализовывать stateful протокол на всех мыслимых и немыслимых вариациях железа и ОС. 3х звенку городить может быть не проще. Особенно если бизнес-логика проста и укладывается в стандартные select/update/insert/delete
Re: Анонсы докладов 3 -й конференции по Firebird
Hello, Alexey! Alexey Popov wrote: Теперь внимание вопрос - что мне надо писать в сокет, чтобы выполнить эту последовательность операций??? возьми исходники клиента .Net или JayBird и посмотри. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Анонсы докладов 3 -й конференции по Firebird
Khorsun Vlad wrote: Диалог не получился... или ты меня не слышишь, или я тебя не понимаю. Попробуем разжевать ещё раз. Предположим у нас есть некая гипотетическая платформа, которая имеет доступ в сеть по TCP. На другом компе крутится FB и слушает порт 3050. Надо сделать следующие вещи: Законнектится на порт FB. Сделать attach к базе. Стартануть транзакцию. Аллоцировать статемент. Препарировать его. Запросить инфу о параметрах. Присвоить параметры. Выполнить. Зафетчить результат. Закрыть запрос. Закоммитить транзакцию. Отсоединиться от базы. Закрыть сокет. Теперь внимание вопрос - что мне надо писать в сокет, чтобы выполнить эту последовательность операций???
Re: Анонсы докладов 3 -й конференции по Firebird
Dmitry Lendel wrote: Про спонсора. Я, примером, не потяну по деньгам такую разработку, но могу внести лепту в общий котел в размере 1000 USD налом и раза в три больше безналом с НДС в грн. В девиз давайте скинемся я не верю. Тут нужно находить заинтересованных. Один есть . :-)) Тут всего то надо нормально специфицировать транспортный протокол на уровне сокета. Сделать один раз это нормально и написание клиента для любой платформы будет очень простым. А сейчас, например, ява и нет клиенты сделаны через одно место с применением реверс инженеринга. В идеале надо бы ещё в gds32.dll транспортный уровень абстрагировать с целью дать возможность задавить свой транспорт.
Re: Анонсы докладов 3 -й конференции по Firebird
Khorsun Vlad wrote: Тут всего то надо нормально специфицировать транспортный протокол на уровне сокета. Протокол - и всё ? Ты или оптимист, или бла-бла-бол :) Давай конкретнее. Например, net клиент юзает напрямую сокет. При этом он придерживается некоторого протокола. Так? Что ещё надо кроме спецификации протокола? Сделать один раз это нормально и написание клиента для любой платформы будет очень простым. Займёшься ? Если говорить о новой платформе, что смысла реализовывать ib api нет. Достаточно написать датасеты, которые напрямую будут работать по сокету с сервером. Это вполне посильная задача для тех, кому это действительно понадобится. В идеале надо бы ещё в gds32.dll транспортный уровень абстрагировать с целью дать возможность задавить свой транспорт. Задавить мы и так могём :) Вопрос в другом, как обычно - смысл где ? Или ради красоты всё ? :) Смысл в том что в современном мире хочется больших извращений. Голый TCP, предоставляемый стандартно, не всегда подходит. Например, FB, как часть большого програмно-аппаратного комплекса, хотелось бы больше интегрировать и адаптировать к обстановке. Люди бывают юзают SSH, но это покрывает лишь малую часть всех задач. А, ещё мелочь забыл - сетевой сервер сам поднимет твой новый транспорт ? Естественно на сервере должна ответная сторона стоять. Например HTTP сервер, транслирующий запросы по локальному протоколу к FB.
Re: Анонсы докладов 3 -й конференции по Firebird
Khorsun Vlad wrote: Почитай src/remote/interface.cpp и src/jrd/why.cpp. На пальцах - клиент поддерживает свои списки аттачей\тр-ций\запросов\курсоров\блобов, кеширует результаты выборки, поддерживает представление XSQLDA\XSQLVAR и т.п. Дык и что? Ясное дело что имеем сильно stateful протокол обмена с сервером. Но в общем случае нет задачи имплементировать ib api. Грубо говоря, пишем класс TQuery, внутри работаем через сокет. Вопрос только в том что написать доку о том, что надо пихать в сокет и читать из него. Во всём этом важно то, что можно диверсифицировать разработку при портировании (т.е. не надо напрягать разработчиков FB)
Re: Анонсы докладов 3 -й конференции по Firebird
Hello, Alex! Alex Cherednichenko wrote: Очень, очень интербейсный ресурс. И тебя с днем рождения!!! :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Анонсы докладов 3 -й конференции по Firebird
Hello, Alex! Alex Cherednichenko wrote: DK И тебя с днем рождения!!! DK :-) Спасибо! :) Я родился в прошлую пятницу. пока я тебя искал, выходные прошли :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
