RE: Анонсы докладов 3-й конференции по F irebird
А какова цена вопроса? Сколько стоит сертификация? когда считал, было (и люди говорили) что минимум в районе 70-100к баксов. Это про гос-сертификацию по безопасности. Наше государство обходится нам все дороже и дороже. А кто занимается сертификацией? Где посмотреть что и как? P.S. У меня ощущение сложилось, что этот закон (ФЗ-153) нарушают 100% предприятий С уважением, Мещеряков Вадим директор ООО Комплексные Системы 454021 г. Челябинск ул. 40 лет Победы 31, 77 Тел: +7 (351) 2807917 Моб: +7 922 6395170 Web: www.del-fin.ru ICQ: 343-554-572 SKYPE: vadimmescheryakov
Re: Анонсы докладов 3-й конференции по F irebird
Alexey Popov wrote ... Khorsun Vlad wrote: Ну написать клиента на какую либо платформу. Каких платформ тебе не хватает ? Где *масса* применений ? Как ты думаешь, почему ява и нет клиенты не хотят использовать gds32.dll и ходят напрямую по сокетам? Почему? Зачем им этот секс? а) они прекрасно умеют использовать fbclient\fbembed б) тормоза при вызове нативного кода из управляемого Сейчас эти клиенты на птичьих правах т.к. используют реверс-инженеринг недокументирванного протокола. А пользуют эти клиенты тысячи. Вот тебе и ответ на вопрос о количестве заинтересованных лиц. Сам придумал про права ? Если им это надо, то можешь поверить что и многим другим это надо. ГДЕ ЭТИ МНОГИЕ ДРУГИЕ ? И какого чёрта они ничего не делают, раз им ТАК СИЛЬНО это всё надо ? Да ну? В существующее api асинхронные возможности встроить практически невозможно, не перелопатив его всего. Конечно, лучше писать новый велосипед, не вникая в старый. Тут уже плакались что старое API не позволяет ввести длинные идентификаторы для объектов в БД. Наверняка аналогичный косяк кстати может всплыть и на уровне протокола. Уровень аргументации просто фантастический Совместимость со старыми клиентами никто не отменял. Клянёшься? Что ещё изволите ? На блюдечке ничё принесть не надо ? А то тут уже намудрили, когда переход от F1.0 и выше происходит с большим скрипом из за проблем с обратной совместимостью. а) что такое 1.0 ? б) о чём ты вообще ? всё ещё о протоколе ? Потом, хоп, скажут, что для работы с FB X.Y клиент от FB 1.0 уже не прокатит и нужно обновить клиента. Будет нужно - скажем. А что - есть возражения ? -- Хорсун Влад PS Наглость просто выше крыши. Так были бы ещё для неё основания...
RE: Анонсы докладов 3-й конференции по F irebird
ага. Это типа как те, кому надо соответствие ФЗ 153, о персональных данных. Т.е. как бы все хотят чтобы ФБ соответствовал, но никто не хочет ни копейки вложить в сертификацию. А какова цена вопроса? Сколько стоит сертификация? С уважением, Мещеряков Вадим директор ООО Комплексные Системы 454021 г. Челябинск ул. 40 лет Победы 31, 77 Тел: +7 (351) 2807917 Моб: +7 922 6395170 Web: www.del-fin.ru ICQ: 343-554-572 SKYPE: vadimmescheryakov
Re: Анонсы докладов 3-й конференции по F irebird
Alexey Popov сообщил/сообщила в новостях следующее: И как будет выглядеть этот модуль? Который должен быть универсальным. А как выглядит тот-же асинхронный АДО, АДО.НЕТ? Он не может вернуть курсор в другой поток, т. к. при разборе результата даже простой isc_fetch должен выполнится асинхронно, т.к. может заброкироваться надолго. В результате бизнес-логику надо размазывать по двум потоком - основным и потоком работающим с БД. А почему размазывание бизнес-логики не происходит при асинхронном использовании сокетов? Наверное потому, что при асинхронном использовании сокетов, приложение изначально проектируется соответствующим образом. И ещё, ИМХО, мы имеем отсутствие аснхронности ещё и потому, что никакие компоненты прямого доступа не приспособленны к асинхронным операциям и для нормальной работы нужно писать свои компоненты, ориентированные именно на асинхронный режим работы или использовать breafcase для работы пользователя, попутно заполняя его результатами асинхронных операций. И не нужно говорить об асинхронности как о панацее, это как и всякий инструмент, кому-то будет к месту, а кому-то нет. :)
Re: Анонсы докладов 3-й конференции по F irebird
Alexey Popov сообщил/сообщила в новостях следующее: Было: первый поток работает с железом, второй работает в БД. Стало: один поток работает и с железом и с БД. А когда мы работали с теми-же платами Диалоджика, делали именно так как Было и именно в парадигме event-driven programing :) Потому, что в уровне работы с устройством, нафиг не нужна была работа с базой, а на уровне работы с базой не нужны возможности работы с устройством. И это наверное было следствием особенностей предметной области И чесно говоря я не понимаю, почему нельзя сделать для себя модуль, который будет асинхронно выполняить запросы к БД, если есть такая необходимость?
Re: Анонсы докладов 3-й конференции по F irebird
Alexey Popov wrote ... Khorsun Vlad wrote: Я же вижу ситуацию так - *он хочет* непонятно чего и зачем, Применений масса. Да ну ? Где ? Я уже давно плачу что необходимо асинхронное взаимодействие с сервером. Кому нужно ? Почему ты один об этом плачешь ? Чтобы поток не тупо ждал ответа сервера в блокирующем режиме, а мог в это время заниматься другими делами. Почему нельзя это реализовать уровнем выше, в DAL ? Допиливать текущее api для этого уже практически невозможно - пациент уже мёртв. Несколько смелое утверждение, не имеющее под собой ни какого обоснования. Проще всего, имея сокетный протокол, работать с сокетами асинхронно, что технически уже давно стало нормой. Я сейчас тоже начну ссылаться на существующие только в моём воображении вещи. Продуктивнейший диалог получится. PS Ещё раз - я не против создания описания текущего протокола. Вот примерно это я и хотел услышать. Но я не хочу этим заниматься, в том числе и потому, что это не нужно не только мне, но и никому другому. Если кто-то хочет этим заняться - буду рад помочь. Кто сказал что лично тебе этим надо заниматься сию минуту? Этим мог бы заняться и кто другой, хоть и я. А к чему тогда этот топик ? Займись, раз оно тебе надо, я же за руки не держу :) Но при условии что этот документ будет принят в качестве стандарта и протокол будет поддерживаться вплоть до конца Вселенной. Это ты не по адресу. Пиши письма в IEEE, SQL Standard Commitee, EC, UN, etc... :-D -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
Alexey Popov wrote ... Khorsun Vlad wrote: Применений масса. Да ну ? Где ? Ну написать клиента на какую либо платформу. Каких платформ тебе не хватает ? Где *масса* применений ? Я уже давно плачу что необходимо асинхронное взаимодействие с сервером. Кому нужно ? Почему ты один об этом плачешь ? Меня можно считать за десятерых :) И спрашивать, как с десятерых ? :) Не надо идти на поводу у большенства. В результате имеем попсу с стиле МС и до сих пор не работающий SMP в супере. Давай ты не будешь меня провоцировать... Народ тупо не понимает что это такое. В оракле кстати есть асинхронность в API. И в MSSQL есть. Спроси меня - сколько раз с 98-го года я ей пользовался. Чтобы поток не тупо ждал ответа сервера в блокирующем режиме, а мог в это время заниматься другими делами. Почему нельзя это реализовать уровнем выше, в DAL ? А кто этот DAL писать/проектировать будет? Для каждого проекта новый? А кто имеющиеся DAL'ы научит пользовать твоё асинхронное АПИ ? :) Надо тупо асинхронно послать sql запрос и получить ответ. Сейчас, да, есть костыли в виде выноса взаимодействия с БД в отдельный поток, но это даёт много проблем и ограничений. Ходим по кругу. Допиливать текущее api для этого уже практически невозможно - пациент уже мёртв. Несколько смелое утверждение, не имеющее под собой ни какого обоснования. Да ну? В существующее api асинхронные возможности встроить практически невозможно, не перелопатив его всего. Конечно, лучше писать новый велосипед, не вникая в старый. Но при условии что этот документ будет принят в качестве стандарта и протокол будет поддерживаться вплоть до конца Вселенной. Это ты не по адресу. Пиши письма в IEEE, SQL Standard Commitee, EC, UN, etc... Стандарта в среде FB, канонизации. Неужели не понятно о чём речь? Не будет никакой канонизации. Для нафига ? Совместимость со старыми клиентами никто не отменял. Но канонизацию протокола - нафига она нам ? Делай описание того, что сейчас есть - и оно будет действительным ещё лет 5, как минимум, пока используют FB 2.x (думаю больше на самом деле). Тем более что планов менять протокол в 3.0 пока тоже нет. -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
Alexey Popov ... Khorsun Vlad wrote: Диалог не получился... или ты меня не слышишь, или я тебя не понимаю. Попробуем разжевать ещё раз. Предположим у нас есть некая гипотетическая платформа, которая имеет доступ в сеть по TCP. На другом И где тут свой транспорт ??? компе крутится FB и слушает порт 3050. Надо сделать следующие вещи: Законнектится на порт FB. Сделать attach к базе. Стартануть транзакцию. Аллоцировать статемент. Препарировать его. Запросить инфу о параметрах. Присвоить параметры. Выполнить. Зафетчить результат. Закрыть запрос. Закоммитить транзакцию. Отсоединиться от базы. Закрыть сокет. Это годится только для приложения вроде hello firebird. Теперь внимание вопрос - что мне надо писать в сокет, чтобы выполнить эту последовательность операций??? Описание всех пакетов и их потрохов живут в protocol + xdr. Какие пакеты требуются для каких АПИ функций - см. interface. Имеющему глаза не нужно ничего другого, кроме этих файлов. Да, авторы .net и java драйверов не имели глаз, когда начинали писать свои реализации протокола обмена. И сейчас часто не имеют, увы. -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
Alexey Popov wrote ... Khorsun Vlad wrote: И где тут свой транспорт ??? Про транспорт это другая, более далёкая, хотелка. Так ты же с неё начал ? Нельзя ли в одной теме обсуждать ОДНУ вещь ? Я теперь вообще не понимаю - чего тебе надобно... Это годится только для приложения вроде hello firebird. Это только пример, реализовав который можно постепенно доработать функционал до желаемого уровня. И называться он будет - новое АПИ. И для текущего набора типов пакетов ты не сделаешь ничего кардинально другого, ибо оно взаимосвязано. Описание всех пакетов и их потрохов живут в protocol + xdr. Какие пакеты требуются для каких АПИ функций - см. interface. Дык я знаю где они живут. Вопрос в том, чтобы специфицировать это на уровне документов аля RFC. Займись, это не сложно. Но и ненужно. Имеющему глаза не нужно ничего другого, кроме этих файлов. Это задаёт слишком высокий ценз для желающих достучаться до FB. Конечно, если человек не в состоянии прочитать и понять простые структуры, он нашет новое гениальное АПИ которого ждёт от него весь мир. На землю спустись :) И посмотри таки на protocol.cpp *открытыми* глазами. Если оно тебе вообще надо. -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
Alexey Popov ... Это только пример, реализовав который можно постепенно доработать функционал до желаемого уровня. И называться он будет - новое АПИ. И для текущего набора типов пакетов ты не сделаешь ничего кардинально другого, ибо оно взаимосвязано. Это само собой. Просто это даст новое качество в портировании. Одно дело пытаться портировать устаревший gds32.dll куда попало. А совсем другое дело имплиментировать задокументированный сетевой протокол. Имплиментируй. Документируй. Чего ты от меня хочешь-то ? На землю спустись :) И посмотри таки на protocol.cpp *открытыми* глазами. Это не наши методы. Точнее не методы для промышленного ПО. Каждый кто хочет использовать это не должен ковыряться в исходниках. Толпы жаждущих использовать это стоят на пороге, а подлый hvlad не пущает. Если оно тебе вообще надо. Мне нада не protocol.cpp, а стандартизация того что там написано. Чуешь разницу? Чую демагогию и очередное бла-бла. Было бы оно тебе НАДО - давно бы сделал. Чуешь разницу ? -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
Arioch ... В письме от Fri, 01 Oct 2010 15:26:39 +0400, Khorsun Vlad сообщал: Мне нада не protocol.cpp, а стандартизация того что там написано. Чуешь разницу? Чую демагогию и очередное бла-бла. Было бы оно тебе НАДО - давно бы сделал. Чуешь разницу ? Мммм а вы потом будете соответствовать? А зачем оно... НАМ ? Захочется вам немножко поменять в этих форматах/пакетах - а нельзя. Типа Алекс уже стандарт принял А кто он такой, что он стандарт принял ? :) Или на каждый чих вводить новую, нестандартную версию протокола тщательно поддерживая совместимость со стандартом Алекса? См. выше Стандарт разработчики вроде бы сами на себе навешивают, добровольно. Именно. В тех случаях, когда это нужно проекту. Да - и не нужно путать документирование со стандартизацией. На всякий случай говорю. Либо задним числом документируют то, что уже лет за 10 окостенело и не изменится. Но тогда зачастую стандарт получается неполный или даже не полностью корректный. Что-то типа документаций протокола ICQ, формата DBF-and-all, недокументированных функций MS-DOS... И кто использует этот стандарт знает, что в принципе всё может легко поменяться в любой день. Если бы Алекс предлагал что-то нужное и полезное - нет проблем поддерживать совместимость или, как минимум, информировать его *до* внесения каких-либо изменений. Я же вижу ситуацию так - *он хочет* непонятно чего и зачем, но *требует от нас* каких-то действий. У нас все, кто работает с протоколом, не имеют проблем заглянуть в исходник и понять что к чему. Делать какую-то документацию (актуальную для 5-10 человек на планете) ради неё самой - извините, нет ни ресурса, ни интереса. Отсюда очень простой вывод - кому нужно, тот сделает. Отдаст назад в проект - хорошо. Будет поддерживать в актуальном виде - совсем хорошо. -- Хорсун Влад PS Ещё раз - я не против создания описания текущего протокола. Но я не хочу этим заниматься, в том числе и потому, что это не нужно не только мне, но и никому другому. Если кто-то хочет этим заняться - буду рад помочь.
Re: Анонсы докладов 3-й конференции по F irebird
Alexey Popov ... Тут всего то надо нормально специфицировать транспортный протокол на уровне сокета. Протокол - и всё ? Ты или оптимист, или бла-бла-бол :) Сделать один раз это нормально и написание клиента для любой платформы будет очень простым. Займёшься ? А сейчас, например, ява и нет клиенты сделаны через одно место с применением реверс инженеринга. В идеале надо бы ещё в gds32.dll транспортный уровень абстрагировать с целью дать возможность задавить свой транспорт. Задавить мы и так могём :) Вопрос в другом, как обычно - смысл где ? Или ради красоты всё ? :) А, ещё мелочь забыл - сетевой сервер сам поднимет твой новый транспорт ? -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
Dmitry Lendel wrote ... Привет. В ближайшее время - я его однозначно не покажу. Но я не единственный кинооператор в этом городе :) Я крутил вертел тему КПК и так и сяк. Рассмотрел все доступные варианты. То что я напишу ниже - это просто мое мнение - не больше и не меньше. 1 Отбрасывать тему КПК - это глупо. Рынок устройств развивается очень динамично. И довольно перспективный. Чего только подачи Гугла в это сфере стоят. Тебе не кажется, что 4 активных разработчика не могут заниматься всем и сразу ? И что полноценная СУБД на КПК не самый востребованный продукт ? 2 Что касается Птицы. Как на меня - в идеале портированная СУБД. Но для начала - портированный клиент. Я смотрю на задачи. Можно использовать MSSQL или LiteSQL. Решене от Майкрософта - это следование линии партии как тут Саша писал. Для локального доступа LiteSQL вполне годится. Врядли на маленьком экране и со слабым процессором кто-то будет городить CRM или ERP. Скорее всего будут делать информационную базу для просмотра с пометками (аля торговый агент, инвентаризация и т.п.) или как в моем случае примитивного клиента on-line. Понятно, что можно использовать и другие технологии, Java например. Но не хочется микроскопом гвозди забивать. Есть ещё .Net провайдер, если говорить о клиенте. Про спонсора. Я, примером, не потяну по деньгам такую разработку, но могу внести лепту в общий котел в размере 1000 USD налом и раза в три больше безналом с НДС в грн. В девиз давайте скинемся я не верю. Тут нужно находить заинтересованных. Один есть . :-)) Это уже конструктивный подход. Но, опять же, деньги не решают всё. Они лишь сдвигают приоритеты. -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
Привет Тебе не кажется, что 4 активных разработчика не могут заниматься всем и сразу ? Сколько нас - 4! Сколько у нас шпаг - 4! и сразу ? И что полноценная СУБД на КПК не самый востребованный продукт ? Не буду я спорить. Я свое мнение высказал Есть ещё .Net провайдер, если говорить о клиенте. Я не очень хочу переходить на эту технологию. Если не будет выхода, тогда да. Это уже конструктивный подход. Но, опять же, деньги не решают всё. Они лишь сдвигают приоритеты. Предложение в остается в силе. Будет получаться, дайте знать. Дмитрий
Re: Анонсы докладов 3-й конференции по F irebird
Alexey Popov wrote ... Khorsun Vlad wrote: Тут всего то надо нормально специфицировать транспортный протокол на уровне сокета. Протокол - и всё ? Ты или оптимист, или бла-бла-бол :) Давай конкретнее. Например, net клиент юзает напрямую сокет. При этом он придерживается некоторого протокола. Так? Что ещё надо кроме спецификации протокола? Почитай src/remote/interface.cpp и src/jrd/why.cpp. На пальцах - клиент поддерживает свои списки аттачей\тр-ций\запросов\курсоров\блобов, кеширует результаты выборки, поддерживает представление XSQLDA\XSQLVAR и т.п. Сделать один раз это нормально и написание клиента для любой платформы будет очень простым. Займёшься ? Если говорить о новой платформе, что смысла реализовывать ib api нет. Достаточно написать датасеты, которые напрямую будут работать по сокету с сервером. Это вполне посильная задача для тех, кому это действительно понадобится. Это ключевые слова кому это действительно понадобится. Есть такие ? Ау, где вы ?! В идеале надо бы ещё в gds32.dll транспортный уровень абстрагировать с целью дать возможность задавить свой транспорт. Задавить мы и так могём :) Вопрос в другом, как обычно - смысл где ? Или ради красоты всё ? :) Смысл в том что в современном мире хочется больших извращений. Голый TCP, предоставляемый стандартно, не всегда подходит. Например, FB, как часть большого програмно-аппаратного комплекса, хотелось бы больше интегрировать и адаптировать к обстановке. Люди бывают юзают SSH, но это покрывает лишь малую часть всех задач. Ничё не понял. О каком конкретном транспорте идёт речь ? А, ещё мелочь забыл - сетевой сервер сам поднимет твой новый транспорт ? Естественно на сервере должна ответная сторона стоять. Например HTTP сервер, транслирующий запросы по локальному протоколу к FB. См выше про ау. Я вот чего не пойму - ты просто пофантазировать вышел (я совсем не против, сам грешен) или для чего это всё было написано ? -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
Alexey Popov ... Khorsun Vlad wrote: Почитай src/remote/interface.cpp и src/jrd/why.cpp. На пальцах - клиент поддерживает свои списки аттачей\тр-ций\запросов\курсоров\блобов, кеширует результаты выборки, поддерживает представление XSQLDA\XSQLVAR и т.п. Дык и что? Диалог не получился... или ты меня не слышишь, или я тебя не понимаю. -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
Смеешься ? Да нет. Почему ты так решил? Давай я тебе в коде исправлю (не знаю, правда, о чём речь :), а уж собирай его сам. Речь идет о том, что портированный клиент под arm вполне работоспособный. Проблема там в том, что он криво работает с данными типа дата и время. Что он возвращает, я не знаю. Получаю просто AV Select iddate from MyTable Если таблица MyTable пустая, то все ок, если есть данные, то AV Сам я врядли соберу. Условия можно обсудить в привате. office DOG pidkova Point biz Дмитрий
Re: Анонсы докладов 3-й конференции по F irebird
Dmitry Lendel ... Смеешься ? Да нет. Почему ты так решил? Потому что система сборки 1.0 - чистый ад, в который я лично не хочу лезть. Потому что система сборки этого неизвестно чего - ещё более адский ад. Потому что инструментов, которыми оно собиралось 10 лет назад, уже не существует, скорее всего. Давай я тебе в коде исправлю (не знаю, правда, о чём речь :), а уж собирай его сам. Речь идет о том, что портированный клиент под arm вполне работоспособный. Чего прыгаешь с WinCE на ARM ? Это не одно и то же. Проблема там в том, что он криво работает с данными типа дата и время. Что он возвращает, я не знаю. Получаю просто AV Select iddate from MyTable Если таблица MyTable пустая, то все ок, если есть данные, то AV Сам я врядли соберу. Условия можно обсудить в привате. office DOG pidkova Point biz См. выше... -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
об этом идет речь http://www.firebirdfaq.org/faq334/ Дмитрий
Re: Анонсы докладов 3-й конференции по F irebird
Потому что система сборки 1.0 - чистый ад, в который я лично не хочу лезть. Потому что система сборки этого неизвестно чего - ещё более адский ад. Потому что инструментов, которыми оно собиралось 10 лет назад, уже не существует, скорее всего. Т.е. кина не будет (с)? Дмитрий
Re: Анонсы докладов 3-й конференции по F irebird
Dmitry Lendel ... Потому что система сборки 1.0 - чистый ад, в который я лично не хочу лезть. Потому что система сборки этого неизвестно чего - ещё более адский ад. Потому что инструментов, которыми оно собиралось 10 лет назад, уже не существует, скорее всего. Т.е. кина не будет (с)? В ближайшее время - я его однозначно не покажу. Но я не единственный кинооператор в этом городе :) -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
Привет. В ближайшее время - я его однозначно не покажу. Но я не единственный кинооператор в этом городе :) Я крутил вертел тему КПК и так и сяк. Рассмотрел все доступные варианты. То что я напишу ниже - это просто мое мнение - не больше и не меньше. 1 Отбрасывать тему КПК - это глупо. Рынок устройств развивается очень динамично. И довольно перспективный. Чего только подачи Гугла в это сфере стоят. 2 Что касается Птицы. Как на меня - в идеале портированная СУБД. Но для начала - портированный клиент. Я смотрю на задачи. Можно использовать MSSQL или LiteSQL. Решене от Майкрософта - это следование линии партии как тут Саша писал. Для локального доступа LiteSQL вполне годится. Врядли на маленьком экране и со слабым процессором кто-то будет городить CRM или ERP. Скорее всего будут делать информационную базу для просмотра с пометками (аля торговый агент, инвентаризация и т.п.) или как в моем случае примитивного клиента on-line. Понятно, что можно использовать и другие технологии, Java например. Но не хочется микроскопом гвозди забивать. Про спонсора. Я, примером, не потяну по деньгам такую разработку, но могу внести лепту в общий котел в размере 1000 USD налом и раза в три больше безналом с НДС в грн. В девиз давайте скинемся я не верю. Тут нужно находить заинтересованных. Один есть . :-)) Вот такие дела... Дмитрий
Re: Анонсы докладов 3-й конференции по F irebird
Привет А с winCE есть какие-то перспективы? Не будет? Дмитрий
Re: Анонсы докладов 3-й конференции по F irebird
Dmitry Lendel ... Привет А с winCE есть какие-то перспективы? Не будет? Рассматривали. Нужно убить (в прямом смысле слова) 4-6 месяцев только на это. Там нет половины нужных АПИ и неизвестно как работает имеющаяся половина. Так что без явного спонсора - увы нет, не будет. -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
Рассматривали. Нужно убить (в прямом смысле слова) 4-6 месяцев только на это. Там нет половины нужных АПИ и неизвестно как работает имеющаяся половина. Так что без явного спонсора - увы нет, не будет. А тот клиент, что уже есть 1.0? Поправить в нем работу с типом date? Дмитрий
Re: Анонсы докладов 3-й конференции по F irebird
Dmitry Lendel ... Рассматривали. Нужно убить (в прямом смысле слова) 4-6 месяцев только на это. Там нет половины нужных АПИ и неизвестно как работает имеющаяся половина. Так что без явного спонсора - увы нет, не будет. А тот клиент, что уже есть 1.0? Поправить в нем работу с типом date? Смеешься ? Давай я тебе в коде исправлю (не знаю, правда, о чём речь :), а уж собирай его сам. -- Хорсун Влад
Re: Анонсы докладов 3-й конференции по F irebird
Комментарии не перестают радовать. :-) А с winCE есть какие-то перспективы? Дмитрий
