https://plus.google.com/u/0/101202723338146589694/posts/R2sPmChehs7
Поскольку она разрослась до "деталей", то хочется кое что процитировать.
"Ничто не мешает.
Только вопрос времени.
Есть проект где маршалинг и сериализация напрочь "перепутаны".
И этот проект правится "на колёсах".
С поддержкой обратной совместимости в real-time.
Тип Int64 в схеме - определён, (и String кстати тоже), а вот DateTime - не определён.
А "раньше" DateTime писался "в обход схемы", как "пользовательские данные". Почему? Это - отдельный вопрос.
Но факт тот, что это стало сильно мешать.
Ибо схема устойчива к изменениям и трансформациям, а "пользовательские данные" - нет.
Тут вы поминали TWriter. Так вот как раз пример из той оперы - "схема" это published-свойства, а "поьзовательские свойства" это - DefineProperty. Надеюсь - это понятно.
Перепутанность маршалинга и сериализации мы как раз "распутываем".
Когда распутаем - всё будет примерно так как Вы говорите - "мухи отдельно, котлеты отдельно".
Да и насчёт "расточать" - это ещё отдельный хороший вопрос. Мерять надо. Время. Траффик. Может быть и "не расточительно" это вовсе."
Кстати - почему ИСХОДНЫЙ вопрос был задан? Да потому, что я - лох - перепутал Double (TDateTime) с Extended.
А в hep заглянуть - поленился.
P.S. Вот такие люди (как я) "вопросы" на форумах и задают. Кому лень в код или help смотреть.
И ещё оттуда же:
"Ну... наш "самопал" проверен годами и объёмами. Хотя к тому же HyTech есть вопросы.
А вот "не самопал" - вопросов вызывает больше.
Может быть у нас (лично у меня) - руки кривые. Допускаю.
Насчёт JSon и XML - да - их проблема в том, что они текстовые. А вот EVD как раз лишён этого недостатка. Он бывает как текстовый, так и бинарный. Причём"прозрачно". И он написан так, что в худшем случае "старый киент" просто проскипует часть данных, которую он "не понял". Сообщив естественно "кому следует".
И аналогично "новый клиент" с успехом прочитает часть схемы "из прошлого".
Несмотря на то, что всё может быть "бинарно упаковано".
Ну и плюс к тому к этому самопалу прилагаются "батарейки" - база кода из нескольких миллионов строк.
Скажем так "на все случаи жизни".
Хотя "самопал" это конечно не есть здорово.
Если приходится делать что-то ПРИНЦИПИАЛЬНО новое, то я стараюсь смотреть в сторону ЧУЖИХ решений, также обкатанных на практике.
Скажем так когда то был тренд - "проще самим написать", чем разобраться в чужом.
Тренд - спорный. Но именно, что спорный.
Потому что плюсы и минусы - можно найти."
Поскольку она разрослась до "деталей", то хочется кое что процитировать.
"Ничто не мешает.
Только вопрос времени.
Есть проект где маршалинг и сериализация напрочь "перепутаны".
И этот проект правится "на колёсах".
С поддержкой обратной совместимости в real-time.
Тип Int64 в схеме - определён, (и String кстати тоже), а вот DateTime - не определён.
А "раньше" DateTime писался "в обход схемы", как "пользовательские данные". Почему? Это - отдельный вопрос.
Но факт тот, что это стало сильно мешать.
Ибо схема устойчива к изменениям и трансформациям, а "пользовательские данные" - нет.
Тут вы поминали TWriter. Так вот как раз пример из той оперы - "схема" это published-свойства, а "поьзовательские свойства" это - DefineProperty. Надеюсь - это понятно.
Перепутанность маршалинга и сериализации мы как раз "распутываем".
Когда распутаем - всё будет примерно так как Вы говорите - "мухи отдельно, котлеты отдельно".
Да и насчёт "расточать" - это ещё отдельный хороший вопрос. Мерять надо. Время. Траффик. Может быть и "не расточительно" это вовсе."
Кстати - почему ИСХОДНЫЙ вопрос был задан? Да потому, что я - лох - перепутал Double (TDateTime) с Extended.
А в hep заглянуть - поленился.
P.S. Вот такие люди (как я) "вопросы" на форумах и задают. Кому лень в код или help смотреть.
И ещё оттуда же:
"Ну... наш "самопал" проверен годами и объёмами. Хотя к тому же HyTech есть вопросы.
А вот "не самопал" - вопросов вызывает больше.
Может быть у нас (лично у меня) - руки кривые. Допускаю.
Насчёт JSon и XML - да - их проблема в том, что они текстовые. А вот EVD как раз лишён этого недостатка. Он бывает как текстовый, так и бинарный. Причём"прозрачно". И он написан так, что в худшем случае "старый киент" просто проскипует часть данных, которую он "не понял". Сообщив естественно "кому следует".
И аналогично "новый клиент" с успехом прочитает часть схемы "из прошлого".
Несмотря на то, что всё может быть "бинарно упаковано".
Ну и плюс к тому к этому самопалу прилагаются "батарейки" - база кода из нескольких миллионов строк.
Скажем так "на все случаи жизни".
Хотя "самопал" это конечно не есть здорово.
Если приходится делать что-то ПРИНЦИПИАЛЬНО новое, то я стараюсь смотреть в сторону ЧУЖИХ решений, также обкатанных на практике.
Скажем так когда то был тренд - "проще самим написать", чем разобраться в чужом.
Тренд - спорный. Но именно, что спорный.
Потому что плюсы и минусы - можно найти."
Комментариев нет:
Отправить комментарий