Порезанный отчет о переписке, кому-то было интересно AB> От деревовидной организации я отказался -- данные доступны
AB> просто по индексу и представляют собой индексированный список.
Реализация Пирамиды в виде линейного списка никоим образом не
усложняет работу сервера. Просто из структур-описателей удаляется
лишняя инфа а на место соответствующих записей в протоколе жестко ставятся
нули.
AB> Плюс к этому уменьшено количество генерируемых и обрабатываемых ошибок.
Сервер Пирамиды в сущности вообще не обязан работать с ошибками.
Реализация ошибок на усмотрение автора сервера.
Только клиент должен работать с ошибками.
AB> Плюс в вашем протоколе отсутствует тип данных "массив" -- а файл это
AB> немного не то, что мне нужно. Нужен именно массив (точнее даже двумерный
AB> массив) с произвольным доступом к элементам.
Интерпретация файла - дело конкретной системы. Структура ли,
массив ли, еще чего. Или требование было втиснуть этот массив в один
кадр? Тоже не проблема - заявить для файла обрабатываемый размер
более размера этого файла - и без проблем.
А так как теперь можно насадить своего клиента на движок пирамиды -
то можно сразу же писать и свою интерпретацию файлов в зависимости
от типа сервера и ID узла.
AB> Нигде в протоколе не видно какой длины может быть строка, когда ее
AB> начнешь модифицировать. Или строки доступны только на чтение?
Проверю текст насчет размера, но подразумевается что строка не может быть
разбита на несколько кадров, соответственно ее длина ограничивается
только длиной кадра для конкретного релиза клиента и сервера. Если
серверу прислали строку длиннее чем он может переварить, он вправе
отказаться от нее или поступить любым другим способом на усмотрение
автора сервера.
Клиент же отобразит столько сколько смог принять.
AB> Насчет длины строки: имеется в виду следующий момент. Допустим у меня в
AB> МК имеется флэшка ограниченного размера, и на одну строку я выделяю
AB> скажем 16 байт. А пользователь захочет записать другую строку -- более
AB> длинную. Как в этом случае поступать? Ведь нигде не оговорена
AB> макисмально допустимая для конкретного случая длина строки. А
AB> закладываться на 256 байт по максимуму -- это может оказаться
AB> затруднительно в отдельных случаях.
Конкретные ограничения параметров закладываются в сервере и
сообщаются клиенту в виде юзерских ошибок. К примеру, можно
определить ошибку длины параметра 0х80 для конкретного релиза, и
даже создать сопроводительный текст к этой ошибке (типа "Very long
string").
А парметр файл здесь подходит почти идеально )).
К тому же никто не мешает завести новый тип данных "array" и
расписать его поведение. Мы внесем его в документ и, возможно,
впоследствии в какой-нибудь из релизов клиента Пирамиды.
Если дочитали до конца - значит вам интересно )))
Ася для Q-A 120418586