Кто будет выделять буфер под тексты ошибок ? Кто будет его
заполнять,
освобождать и когда ? Что-то я вас не понимаю...
Аналог ib_alloc но в другую сторону. Выделяется память в клиентской
либе, а если приложение хочет освободить память вызывает ib_deallock.
Дико, но работать будет.
Ужас какой :) А зачем ? Кто сейчас запрещает распарсить вектор и
скопировать к себе все строки ? Причём только тогда, когда это надо.
Никто. Jaybird в JNI-режиме так и делает. Но тогда нам не надо будет
нового варианта клиентской либы.
Ты не сказал зачем это нужно.
А я чё? Я - ничё. Это все Дима затеял - изменить сигнатуры всех методов
так, чтоб не передавать указатель на ISC_STATUS в них, а вместо этого
вызывать что-то типа isc_get_last_error.
Я же аргументировал, что тот факт, что ISC_STATUS валидный только до
следующего вызова большинства методов не является причиной менять АПИ,
так как АПИ здесь ни при чем и это только такая реализация этого АПИ. И
что возможно создать другую реализацию, где все будет по-другому. И Дима
согласился. Ну а потом Ты проснулся с вопросом "А как?!" :) Вот я и
сгенерировал идею.
Кстати, у меня еще много разных идей сегодня после обеда появилось.
Например ввести новые методы, которые еще и аллокатор как параметр
получают. Тогда можно вообще память от приложение получать. :) Я еще
подумаю, у меня еще идеи появится! :)
И я совсем уже потерялся - о какой
новой либе идёт речь ?
Кто-то (например я) возмется и напишет свой вариант клиентской либы.
Например сгенерирую DLL с теми же точками входа, которая будет грузить
Java Virtual Machine и вызывать нашу реализацию сетевого протокола.
Но шутки в сторону. Это (написать новую либу) действительно можно
сделать, при чем можно сделать ее очень маленькой и такой, что сможет
быть запущена на Pocket PC или Symbian. TCP-стэк у них у всех есть, а
возможность подключатся к ФБ может быть аттрактивной для встраеваемых и
мобильных приложений.
Хотя есть ли смысл в таком варианте без возможности делать хоть часть
обработки данных локально?..
Роман
