с одной стороны получается
- xml
- парсинг на сервере
- парсинг на клиенте
с другой
- протокол (в каком формате, кстати?)
- парсинг на сервере
- генерация на сервере
По трудозатратам примерно тоже самое (однако со вторым случаем придется повозиться с генератором swc/swf/as3).
Но, как я понимаю есть один большой плюс: работа с протоколом сосредоточена в одном месте - на сервере, т.е. осутствуют проблемы синхроницации протоколе, сложнее ошибиться на клиенте.
А если вспомнить про динамику - то сложнее ошибиться и при отправке/обработке запроса

Но, ИМХО для проектов средней сложности дешевле работать с парсингом, меньше граблей, на которые можно напороться, нет?

Я сначала подумал, что сервер парсит swf-ку :wacko:, а она еще отку-да-то генерится, но раз это не так, то вопрос не имеет смысла.

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

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

Более-менее понятно.
Т.е. протокол - это просто доки получается. А объекты то сами откуда берутся, из базы?
Или "Я клиент, ничего не хочу знать, кроме того, что здесь лежить swf со статикой, а вот на эти запросы мне вернут динамику, которую я просто дисериализую в типизированные объекты?"

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

Просто точка "!№;;!! Опять изменился протокол, где это долбаное поле?!! Что здесь должен присылать сервер!!?" была очень-очень далеко и так и не наступила по сравнению с другими проблемами.

Замысел в том, что AS класс не нужно самому писать - его должно что-то генерить. Генерация - вопрос не сложный. Сложность заключается в правельной передаче информации. А тут XML плохо подходит, т.как нет прямого соответствия типов.
Второй недостаток никак этим не "лечится" - как вы из XML поймете, что объект создается по ссылке (т.е. не создается вообще)?

XML нужен для людей, а не ЭВМ. Передача информации в этом формате сопряжена, как сказал бы мой коллега, с большим оверхедом. Сравните русский и английский языки. Первый для передачи эмоций.
Но если вы читаете байткод как Кира Булычева, то можете игнорировать мои заявления.

Да нет такой связи... XML - только один из возможных форматов, со своими недостатками. Вообще изначально даже не задумывался для хранения информации, только для презентации. Тот же Protobuf при том, что в исходнике не менее читаемый, не страдает такими недостатками.

Кстати, раз уж мы заговорили о презентации информации, то, например, предствить табличные данные так, как это делает SQL - это гораздо более читаемо, чем XML. Там сaрзу же и на колонки разбито, и выравнено + заголовки над колонками говорят о типе и назначении поля - гораздо удобнее что-то искать / сравнивать значения и т.п.

Да есть такая связь, есть. Но я уважаю чужое мнение и не могу с ним не согласиться.
Зачем для передачи информации (все помнят, что такое бит?) кодировать бит с оверхедом over 9000?

Не могу не согласится, просто мне в этом направлении знаний/опыта пока не хватает.

Значит dimarik за честную (де)сериализацию? Где вы таких покладистых серверных прогеров находите? :о))

dimarik, а как вы храните динамические структуры? Поделитесь опытом

Под статикой для "фермы", вероятно, подразумевались прототипы объектов в рамках предметной области приложения. Имеем один раз сформированный файл (я предложил, в формате swf) со списком таких предметов (синонимы: артикул, шаблон). Например, есть предмет на грядке protoId=1, id=1, count=2. По protoId узнаем остальные характеристики (цвет, название, стоимость, что-то еще, что общее для такого типа объекта) предмета из статического списка. Собрали с грядки один предмет (count-1), получили второй предмет protoId=1, id=2, count=1. Первый предмет изменил свой count на count=1. Так вот динамика передается сервером и определяет что остается на грядке и что собрано.

Вернемся к вашему вопросу. Динамические структуры я не храню. Я меняю модель. Если модель динамическая структура, а она динамическая, то я храню ее... в памяти ) В общем, я не понял вопроса.