Какой выбрать разделитель при передаче параметров

← →
Mephala (2008-09-05 10:47) [0]

Доброго всем дня!
Необходимо параметры функции записать в строку, а затем строку распарсить и выбрать оттуда все параметры (пишется провайдер между программами). Параметрами могут быть, как числа, дата и время, текст, так и массивы, ссылки и объекты.
Среда разработки - Delphi 7.
Какой лучше выбрать для этого разделитель? Точка с запятой, запятая, пробелы могут встретиться в тексте, ковычки - тоже не очень как-то.
Может кто-нибудь сталкивался с такой проблемой? Поделитесь, пожалуйста, опытом.
Спасибо!

← →
Юрий Зотов © (2008-09-05 10:51) [1]

Тот символ, который в тексте точно не встретится. Например, #7.

← →
Сергей М. © (2008-09-05 10:52) [2]

> пишется провайдер между программами

Похоже, что изобретается очередной велосипед ..
В системе есть куча готовых технологий интерпроцессных коммуникаций.

> Какой лучше выбрать для этого разделитель?

Тот что заведомо не может фигурировать ни в одном из параметров.

← →
Vlad Oshin © (2008-09-05 11:08) [3]

любой
а если нужно передать такой же, он передаётся дважды.
принцип апострофа в delphi

← →
Медвежонок Пятачок © (2008-09-05 11:31) [4]

xml

← →
Mephala (2008-09-07 12:02) [5]

Спасибо большое за ответы. Получается, что одни из лучших - это xml и удвоение символа. А если будут еще передаваться и бинарные данные в строку, то какой из этих лучше использовать?
Сама понимаю, что от велосипедов не деться. Суть такая, что из дельфовой программы нужно передать в хранимую процедуру СУБД (dll) входные параметры. А так как количество входных параметров может быть разным для разных функций, то было принято решение занести все параметры в один. Если у вас есть лучшее решение и пр., то буду рада любой критике :)

И еще вопрос: какие существуют классы, методы, объекты, чтобы парсить и формировать xml? С этим еще не сталкивалась. Буду рада помощи.
Спасибо!

← →
Сергей М. © (2008-09-07 18:24) [6]

В виде БЛОБ-параметра можно хоть черта лысого передать..

СУБД-то какая ?

← →
Юрий Зотов © (2008-09-07 18:46) [7]

> Mephala (07.09.08 12:02) [5]

> Получается, что одни из лучших - это xml

Для этой задачи - что из пушки по воробьям палить. На второй этаж тоже можно подниматься на вертолете, но зачем? Гораздо проще, быстрее и дешевле пешком пройти.

> и удвоение символа

Что приведет к усложнению последующего разбора. И, кроме того - что будет, если юзер все же впечатает этот двойной символ? Ему не запретишь.

=================

Чем не устраивает любой непечатный символ, хоть тот же #7 ? Формирование строки - элементарно простое, ее разбор - тоже.

← →
Медвежонок Пятачок © (2008-09-07 21:14) [8]

xml

← →
Медвежонок Пятачок © (2008-09-07 21:24) [9]

импортировать библиотеку типов msxml и воспользоваться IXMLDomDocument2

← →
KilkennyCat © (2008-09-07 21:42) [10]

> И, кроме того - что будет, если юзер все же впечатает этот
> двойной символ? Ему не запретишь.

четыре символа, соответственно....

← →
Медвежонок Пятачок © (2008-09-07 22:10) [11]

круглое - носить, квадратное - катать.

← →
KilkennyCat © (2008-09-07 23:11) [12]

а треугольное?

← →
Медвежонок Пятачок © (2008-09-07 23:40) [13]

треугольное после сборки обработать напильником

← →
Германн © (2008-09-08 00:57) [14]

> треугольное после сборки обработать напильником
>

Может лучше сначала подумать и не собирать треугольное?
Плавали знаем. Было как-то. Собирали на нашем в МИФИ заводе установку разработанную нашим же МИФИ конструкторском бюро. И нифига не понимали как соединить два фланца. У одного было шесть отверстий для болтов, а у другого восемь! Тут никакой напильник не поможет.
:)

← →
KilkennyCat © (2008-09-08 07:48) [15]

> И нифига не понимали как соединить два фланца. У одного
> было шесть отверстий для болтов, а у другого восемь! Тут
> никакой напильник не поможет.

зато поможет математика! у 6 и 8 общее кратное 2. значит, на два болта.

← →
Медвежонок Пятачок © (2008-09-08 09:05) [16]

непечатные символы, удвоение, прочая хрень....
как хорошо, что веб сервисы придумали намного более незамысловатые люди.

← →
Mephala (2008-09-08 10:44) [17]

Непечатные символы по идее тоже могут встречаться, если будут передавать двоичные данные...
XML, согласна, будет тяжеловесным решением. По идее, нужно будет все обрабатывать как можно более производительнее, а то будет узким местом в системе.
Появилась идея формировать заголовок в виде: длина параметра - параметр - длина второго параметра - второй параметр и т.д. Разбор вроде, как и формирование, может быть достаточно быстрым - один цикл понадобиться для строки. А вот для удвоения придется уже несколько циклов делать.
Что скажите?

← →
Mephala (2008-09-08 10:45) [18]

Да, кстати, СУБД - Advantage SQL.

← →
Медвежонок Пятачок © (2008-09-08 10:47) [19]

Что скажите?

скажу что клево все это

← →
Юрий Зотов © (2008-09-08 10:57) [20]

> Mephala (08.09.08 10:44) [17]

> если будут передавать двоичные данные...

Так бы сразу и говорили, а то - строка, строка...

Для произвольных данных решение может быть таким:

Количество элементов (4 байта).
По каждому элементу: длина его данных (4 байта), затем сами данные.

Передавать можно, например, через сообщение WM_COPYDATA.

← →
Медвежонок Пятачок © (2008-09-08 11:00) [21]

.... И после того, как будут зарелизены первые версии провайдера и клиенты, и придет время когда потребуется изменить перечень параметров, и это будет сделано, то все разработанное ранее, касающееся разбора параметов, переписываем с нуля.

это наш путь.

← →
Юрий Зотов © (2008-09-08 11:03) [22]

> Медвежонок Пятачок © (08.09.08 11:00) [21]

Предложите другой путь. Когда структура передаваемых данных меняется, а в код принимающей стороны не требуется вносить изменений.

Есть такой способ?

← →
Медвежонок Пятачок © (2008-09-08 11:09) [23]

я уже предложил.
xml.

первая версия протокола передавала три параметра-строки.
зарелизили.
потребовалось больше параметров.
Между вторым и третьим параметрами вставили двумерный список (три элемента в каждом четыре значения)

Старые клиенты продолжают работать как ни в чем ни бывало.
Для получения новых параметров в новом клиенте дописываем код чтения (фактически добавляем новые xpath выражения в алгоритм)

← →
Юрий Зотов © (2008-09-08 11:24) [24]

> Медвежонок Пятачок © (08.09.08 11:09) [23]

То есть, все равно пишем нового клиента. В чем же преимущество?

Применяем такую структуру данных:
Длина параметра - тело параметра, длина параметра - тело параметра...

И используем WM_COPYDATA. Количество параметров и их последовательность клиент знает сам.

Потребовалось добавить новые параметры. Добавляем их в конец (согласитесь, что без разницы, куда именно их добавлять). Старые клиенты работают, как работали, а новые клиенты юзают новый протокол.

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

Недостатки - налицо, а преимуществ - никаких. И на фига ж тогда козе баян?

← →
Медвежонок Пятачок © (2008-09-08 11:34) [25]

преимущества в декларативном характере алгоритма чтения. принимающая сторона не заморачивается с необходимостью знания физического порядка данных в передаваемом блоке.

← →
Медвежонок Пятачок © (2008-09-08 11:37) [26]

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

← →
Юрий Зотов © (2008-09-08 11:38) [27]

> Медвежонок Пятачок © (08.09.08 11:34) [25]

> преимущества в декларативном характере алгоритма чтения.

Это всего лишь слова.

> принимающая сторона не заморачивается с необходимостью
> знания физического порядка данных в передаваемом блоке.

Зато она заморачивается с необходимостью знания имен параметров (тегов). Что, по сути, то же самое, только существенно медленнее и существенно более громоздко.

← →
Медвежонок Пятачок © (2008-09-08 11:39) [28]

Что, по сути, то же самое,

только в разы более гибкое и более сопровождаемое в разы.

← →
Юрий Зотов © (2008-09-08 11:41) [29]

> Медвежонок Пятачок © (08.09.08 11:37) [26]

> кроме того, параметры могут не только добавляться, но и
> удаляться.

Могут.

> мой способ в этом случае в старой версии прочитает пустоту

Прочитает.

> ваш способ прочитает мусор

Нет. Мой способ тоже прочитает пустоту (длина равна нулю). Только сделает это намного быстрее Вашего.

← →
Медвежонок Пятачок © (2008-09-08 11:43) [30]

Нет. Мой способ тоже прочитает пустоту (длина равна нулю). Только сделает это намного быстрее Вашего.

Он быстрее моего в разы прочитает мусор для всех параметров после удаленного.

← →
Юрий Зотов © (2008-09-08 11:43) [31]

> Медвежонок Пятачок © (08.09.08 11:39) [28]

> только в разы более гибкое и более сопровождаемое в разы.

Это тоже всего лишь слова. А конкретно - пока что я не увидел ни большей гибкости, ни лучшей сопровождаемости. Зато вполне отчетливо вижу довольно сильные тормоза и довольно значительное распухание данных.

← →
Юрий Зотов © (2008-09-08 11:45) [32]

> Медвежонок Пятачок © (08.09.08 11:43) [30]

> Он быстрее моего в разы прочитает мусор для всех параметров
> после удаленного.

С чего это?

← →
Медвежонок Пятачок © (2008-09-08 11:46) [33]

Это тоже всего лишь слова.

Это правда жизни.
Ваш метод прочитает мусор для удаленного параметра и всех остальных. Так как заточен на физический порядок их следования.

И это не просто слова, а реальность.

С чего это?

Да с того самого.
Читающий алгоритм знает, что вот сейчас идет длина строки, затем сама строка, затем дворд, затем снова длина строки после чего строка.

Удаляем один параметр и весь алгоритм улетает в космос.
А с xml будет считан один пустой параметр, все остальные останутся на своих местах со своими значениями.

> Медвежонок Пятачок © (08.09.08 11:46) [33]

> Это правда жизни.
> И это не просто слова, а реальность.

А давайте обойдемся без пустопорожних заявлений? Красивые слова я умею говорить не хуже Вас, поверьте. И опыт в построении гибких решений (когда оно действительно нужно), в поддержке и сопровождении тоже имею, и тоже вряд ли меньше Вашего.

Но здесь стоит вполне конкретная задача. Та что - давайте конкретно о конкретной задаче и потолкуем, ладно?

> Ваш метод прочитает мусор для удаленного параметра и всех остальных.
> Так как заточен на физический порядок их следования.

Еще раз - ни фига подобного. Параметр удаляется, например, простановкой отрицательной длины и пустого тела. И весь вопрос.

Еще раз - ни фига подобного. Параметр удаляется, например, простановкой отрицательной длины и пустого тела. И весь вопрос.

О чем я и говорю. Для вашего метода удаление одного параметра - фатально для прежних версий алгоритма. И вы вынуждены совать в передаваемый блок заглушку.

И я полностью согласен с предложением "поменьше пустых слов"
Осталось и вам последовать ему.

вся продвинутость самопального велосипеда: часы заьраченные на реализацию протокола и несколько выигранных у меня миллисекунд на рантайме.

у меня - минуты на разработку и сопровождение и несколько проигранных миллисекунд на рантайме плюс несколько десятков/сотен лишних байт-тегов.

все.

> Медвежонок Пятачок © (08.09.08 11:48) [34]

> Читающий алгоритм знает, что вот сейчас идет длина строки, затем сама
> строка, затем дворд, затем снова длина строки после чего строка.

Пожалуста, будьте внимательнее. Читающий алгоритм знает, что идет длина параметра, затем тело параметра. А никакие не строки и не DWORDы. Это уж он сам решает, как ему считанный параметр интерпретировать.

Собственно, это же самая обыкновенная задача сериализации в бинарный поток, реализованная уже несчетное количество раз.

> Удаляем один параметр и весь алгоритм улетает в космос.

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

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

<Цитата>

И в сотый раз: и где здесь удаленный параметр?
Он больше не нужен, но для того, чтобы прежние версии не дали дуба, вы вынуждены оставлять его в потоке.

> Медвежонок Пятачок © (08.09.08 11:58) [36]

> И я полностью согласен с предложением "поменьше пустых слов".

Ссылку, плз - где в этой ветке я пускался в философские рассуждения о правде жизни и ее реалиях? Конкретно.

> Осталось и вам последовать ему.

Я и последую. Поскольку споре с Вами, как выяснилось, любые слова действительно оказываются пустыми, я просто не буду произносить никаких слов. Чао.

Да ради бога.
Я утверждал и утверджаю, что xml решение более гибко, более быстро реализуемо, и менее трудоемко поддерживаемо.

В ответ не аргументы - а только пустые слова про "это только слова"

Автору вопроса:
Главные итоги ветки можно найти в [37]

> xml решение более гибко, более быстро реализуемо, и менее
> трудоемко поддерживаемо.
>

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

> Он больше не нужен, но для того, чтобы прежние версии не
> дали дуба, вы вынуждены оставлять его в потоке.

А кому он там мог помешать? Раньше использовался, теперь нет - ну длина нулевая для обратной совместимости. Или это маниакальное желание сэкономить 4 байта? Дык в xml проигрыш по размеру заведомо больше.

Единственным доступным моему пониманию плюсом xml является текстовый вид данных, который удобен там, где эти данные кто-то будет править руками. Однако, речь вроде шла о бинарных данных, так что сей плюс неактуален. А значит реализовывать нужно то, что автору удобнее. Мне в случае с бинарными данными, удобнее сделать простетский бинарный формат вроде того, что в [20]. Потому что парсеров xml развелось немало (я штук 6 находил под делфи, искал не слишком усердно), у каждого свои недостатки (а зачастую и баги). Тогда как бинарный формат из серии "простота залог здоровья", весь код мой, и, я подозреваю, он уместится на одном экране (т.е. вероятность наличия в нем ошибки очень близка к нулю).

Если же предполагается большое количество текстовых полей (и хочется, чтобы эти текстовые поля можно было легко редактировать вне программы) вместе с бинарными, то xml удобнее. Но это справедливо для всяких конфигов, больше пользователю как правило свой нос в файлы сувать незачем. Для всего остального бинарный формат ничуть не хуже.

мир всегда кажется таким простым, когда ветку читаешь по диагонали и с середины.

← →
Mephala (2008-09-09 11:37) [46]

Да уж, дискуссия получилась горячей, однако! :) А главное - интересной и информативной.
Что же касается удаленного параметра, то в нашем случае с этим проблем нет: так как хранимые процедуры на sql и передаваемые параметры с клиента формируются и изменяются синхронно. А моему провайдеру все равно - сколько там параметров.
Узким местом в моей задаче является время выполнения моей дельфовой хранимой процедуры по обработке входящих параметров. XML безусловно хорош, но в рантайме, да еще с сотней пользователей - это будет беда, имхо. К тому же у нас еще используются коды в режиме JIT, что тоже заставляет задуматься о производительности.
Поэтому мне больше понравилась идея Юрия Зотова, за что ему отдельное спасибо :).
Всем большое спасибо за отклик! Поверьте, узнать опыт профессионалов-практиков, дорого стоит. :)

Затраты времени на парсинг хмл будут на порядки ниже времени отклика sql сервера.
Так что ко второму пришествию сумеешь в совокупности сэкономить минут двадцать, не применяя xml.

А моему провайдеру все равно - сколько там параметров.

Ему не все равно. Он всегда точно знает их порядок в стриме и ждет что они придут все именно в таком порядке.

Да, кстати, СУБД - Advantage SQL.

не знаю как там в экзотических субд, но все нормальные типа оракла и мсскл поддерживают xml типы. то есть я бы вообще не парился с парсингом параметров в прокладке-провайдере, а передавал бы весь xml прямо в хранимку.

Какой выбрать разделитель при передаче параметров Найти похожие ветки