Здравствуйте, meadow_meal, Вы писали:

_>Ты понятие IDL трактуешь очень узко, IDL это не только CORBA и COM.

Я тебе дал вполне конкретное представление о том, что есть IDL, не наговаривай на конкретно CORBA или COM.
Почитай про тот же ICE:
https://en.wikipedia.org/wiki/Internet_Communications_Engine

В этом месте тебе должно быть уже понятно отличие Google protobuf или Microsoft bond от фреймворков подобного рода.
Не надо путать фреймворки сугубо для бинарной сериализации и фреймворки для удалённых вызовов методов объектов.

Потому что в первом случае ты сам работаешь напрямую с транспортным слоем, а во втором тебе транспортный слой, считай, не видим ("прозрачен", согласен IT-терминологии).

Поэтому, коль я по косвенным признакам догадался о неверном использовании тобой абревиатуры IDL, я предложил тебе фреймворк другого типа — ASN.1.
Почему именно он — он лучший на сегодня из всех.

Даже если тебе не нравится сам ASN.1 — я уже сказал что надо делать — надо просто написать свой примитивнейший DSL, который на выходе даст ASN.1.

Хотя, даже сам ASN.1 весьма удобен, просто надо потратить хотя бы час-другой времени на его изучение. Например, в этом языке есть ЯВНАЯ поддержка optional-семантики.

А еще в языке есть параметрические типы. ))
Т.е. можно задать генерик-описание сообщения, например:

Point{DataType} ::= SEQUENCE {
    x DataType, 
    y DataType
}

Зависимости можно протягивать:

Move{DataType} ::= SEQUENCE {
    from Point{DataType}, 
    to   Point{DataType}
}

а потом специализировать

UpdateXXX ::= CHOICE {
    i [0] Move<int32>, 
    f [1] Move<float>,
    d [2] Move<double>
}

А еще для этих параметрических типов можно описывать классы типов:

LevelParams ::= CLASS {
    &level-field-width int32,
    &level-field-height int32,
}

Move-PDU{LevelParams : param} ::= SEQUENCE {
   x INTEGER (0..param.&level-field-width),
   y INTEGER (0..param.&level-field-height)
}

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

Есть еще много других прикольных плюшек, чего стоит один только тип SET — это же бомба!

Кароч, я много одно время смотрел альтернативных технологий, но они по выразительности и мощи проигрывают ASN.1, как первоклашки проигрывают профессору ВУЗ-а в области математики. ))


_>Я на это тоже уже отвечал. ASN.1 compiler генерирует то, что генерирует, а не то, что мне нужно.

У некоторых компилятором маппинг можно настраивать.


_>При этом кодогенерация вообще никак не контролируется, системы метаданных как например в protobuf у него нет.

Опять же — есть:
http://bnotes.sourceforge.net/

Вот тебе с метаинформацией для C#:

[ASN1Sequence ( Name = "TestSequence", IsSet = false )]
public class TestSequence 
{
    private long field1_ ;

    [ASN1Element ( Name = "field1", IsOptional = false , HasTag = false , HasDefaultValue = false ) ]
    public long Field1 {
        get { return field1_; }
        set { field1_ = value; }
    }
...

_>То есть в Эрланге тупл вместо рекорда — нельзя, typespec — нельзя, в C# struct вместо class — нельзя, использовать алиас на существующий тип данных указав для него внешний сериализатор — нельзя, сгенерировать Equals/EqualityComparer/или что еще в голову взбредет — нельзя.

Здра моя ра!
А не путаете ли вы, батенька, транспортный слой с прикладным?
Или у тебя там всё вперемешку?

Блин, во всех этих сетевых делах ничего изобретать не надо — всё уже изобретено до нас. Например, любые обращения к серверу БД — это точно такое же обращение к сетевому внешнему сервису. И точно так же существует некий слой DAL, дальше которого сугубо транспортные типы данных не пролезают.


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

Потому что ты уткнулся в архитектуру без DAL.


_>То есть используя ASN.1 как таргет-язык для генерации, я просто не могу решать те задачи, которые ставлю перед исходным DSL.

ASN.1 тут не при чем от слова совсем, хосподя...

Я тебе предлагал на основе BLToolkit сделать автоматический маппинг с транспортного слоя на прикладной.
Я же говорю — ты не понял НИ СЛОВА из того, что я писал тебе ранее.
Даже где-то обидно... ))


_>Но главное даже не это. Даже если б это было возможно, но — нахрена? Я бы понял, если б ты предложил ASN.1 или что еще как основной язык (но в случае с ASN.1 это полное безумие), но как промежуточный?

Потому что эффективная и надежная сериализация. Т.е. чтобы не тратить квантов внимания на эту область, в которой в случае ручной её реализации постоянно возникают ошибки и вообще оно происходит зачастую неэффекктивно.

А еще потому, что ASN.1 предлагает тебе trade-off изкаробки: можно выбирать из целой градации профилей кодирования, от самых эффективных по размеру пакета до самых эффективных по затрачиваемым ресурсам проца. И тебе несложно будет переключать эти профили. Например, если у какого-то клиента плохой пинг, то серверу стоит ужать трафик в сторону такого клиента в НЕСКОЛЬКО РАЗ. А если хороший, то стоит тратить на такого клиента меньше тиков процессора.

Никакая другая технология вот всеми этими совокупными св-вами НЕ обладает. Более того. На сегодня идёт развитие в нужном направлении только ASN.1.
Остальные конкурирующие технологии мертвы — будучи разработаны однажды для чего-то, быстро становятся невостребованы по окончании проекта, в котором были применены. Эдакая "одноразовость", мертвечинка...


_>Но я не понимаю, в чем именно ты видишь проблему генерации кода сериализации. В самой кодогенерации или в оптимальности сгенерированного кода?

И там и там.
А еще в ошибках, т.е. тупо в багах. Был я как-то на одном проекте, так только в коде бинарной кастомной сериализации отловил порядка десятка ошибок. Причем, ошибки удачно максировались тем, что периодически шла не только дельта, но и абсолютные значения, угу. Поэтому ошибки в дельтах приводили лишь к "кратковременному вранью", которое списывали на притормаживание. )) А не было никакого притормаживания, были баги.


V>>Потому что удобных инструментов для разработки своих языков полно.
_>Разве с этим кто-то спорит?
V>>ANTLR
_>Ну и что ANTLR-то? Nemerle.Peg не сложнее

Он не не сложнее, а беднее на многие-многие порядки. Он пуст как абстрактное zero. Как Мухосранк посреди Сибири. ))

Ты, таки, взял бы в руки ANTLR. Это мощнейшая визуальная система разработки и отладки грамматик.
В принципе, ПОСЛЕ отладки грамматики в ANTLR запросто можно закодировать её в чем угодно, хоть даже в Nemerle.

В ANTLR ты можешь вести быструю разработку языка, вводить новые конструкции в него и достоверно на каждом шаге знать — получается ли у тебя язык однозначным на любых входных цепочках или уже нет. В случае PEG ты об этом не узнаешь до тех пор, пока тебе на входе не встретится такая цепочка. И вот ты создашь в JIRA тикет, вынужден будешь открыть исходник своего парсера и начать медитировать.


_>а удобная интерполяция строк как в Nemerle это musthave для кодогенерации.

Да это вообще для кодогенерации пофиг. Экономия 1% усилий. Проблема чаще не в кодогенерации, а в модели, по которой она происходит. А модель зависит от языка. А вот разработать сам язык — это и есть самая мякотка.


_>Прочитал, но не понял, на что ты обиделся.

Я не принимаю простых "я не согласен", "тут не прав", "а это грязный хак" (чего???) и прочей такой фигни.

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

И т.д. в этом же духе.

Всё остальное — это просто обмен какашками, в какую бы вежливую форму они ни были завёрнуты.