Сериализация и языки
От: gandalfgrey  
Дата: 24.11.08 09:20
Оценка: 2 (1)
Здравствуйте, eao197, Вы писали:

E>Ситуация несколько сложнее. Язык версии 1.* вроде как есть и поддерживается пока только одним компилятором DMD на платформах x86 Windows и Linux. Под него существуют некоторые библиотеки. И все. Совершенствованием 1.* больше никто не занимается. Новые библиотеки создаются уже для 2.*. Даже у Tango появилась ветка для D 2.0, хотя сама Tango так до 1.0 пока и не дошла.

Чего это вдруг одним компилятором ? Д 1.хх имеет фронтенд для Гнуси, и тем самым для всего-всего.

E>Т.е. если сейчас заложиться на диалект 1.* для долгосрочных проектов, то это означает, что в скором времени эти проекты окажутся привязанными к умершей ветке языка с ограниченным количеством инструментов и библиотек. Поскольку я не слышал о том, что кто-то хочет дальше заниматься D 1.0.

На самом деле перенос либ между 1.хх и 2.хх несложен. Я переносил DFL на 2.хх без напряга.

E>Я читаю только news.digitalmars.announce, про паттерн-матчинг не слышал.

Вроде бы это обсуждалось в Digitalmars.D

E>Тупли там на основе шаблонов. Имхо, более простые в освоении и использовании, чем в C++0x.

Их нельзя возвращать из функций, к сожалению.

E>У вас же есть Erlang, зачем вам что-то еще?

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

E>К статически-типизированным языкам типа C++/D даже невстроенная сериализация с продвинутыми возможностями приделывается на раз.

Как это ? Наверное, у меня мозга не в том направлении думает.. Поясните, плиззз



28.11.08 15:54: Ветка выделена из темы C++0X vs D programming lang
Автор:
Дата: 16.11.08
— AndrewVK
Re: Сериализация и языки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.11.08 09:32
Оценка: 2 (1)
Здравствуйте, gandalfgrey, Вы писали:

G>Чего это вдруг одним компилятором ? Д 1.хх имеет фронтенд для Гнуси, и тем самым для всего-всего.


По имеющимся у меня сведениям, GDC приказал долго жить. А его разработчик подключился к разработке комплятора D на основе LLVM.

G>На самом деле перенос либ между 1.хх и 2.хх несложен.


Ну ей богу, зло берет по 10 раз все это объяснять. В 2.* появилась транзитивная константность. Все. Любой старый D-шный код, который хочет получить существенные преимущества от D 2.* (за счет иммутабельности, например), должен быть не просто переписан, а перепроектирован.

G>Я переносил DFL на 2.хх без напряга.


А DFL, насколько я помню, всего лишь биндинг к FLTK.

E>>К статически-типизированным языкам типа C++/D даже невстроенная сериализация с продвинутыми возможностями приделывается на раз.

G>Как это ? Наверное, у меня мозга не в том направлении думает.. Поясните, плиззз

ASN.1, Google Protocol Buffers, Boost.Serialization, s11n.net, даже мой собственный велосипед ObjESSty -- все это работает без встроенной поддержки со стороны языка.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Сериализация и языки
От: gandalfgrey  
Дата: 24.11.08 10:46
Оценка:
Здравствуйте, eao197, Вы писали:

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

E>По имеющимся у меня сведениям, GDC приказал долго жить. А его разработчик подключился к разработке комплятора D на основе LLVM.
LLVM только для 2.хх будет ?

E>Ну ей богу, зло берет по 10 раз все это объяснять. В 2.* появилась транзитивная константность. Все. Любой старый D-шный код, который хочет получить существенные преимущества от D 2.* (за счет иммутабельности, например), должен быть не просто переписан, а перепроектирован.

Ключевое слово — "который хочет". Если надо просто перенести ( чтоб собиралось и работало ) — то это несложно

E>А DFL, насколько я помню, всего лишь биндинг к FLTK.

DFL, the D Forms Library, is an easy to use user interface toolkit for the D programming language. It brings you a high level, easy to use interface, abstracted from the native API.
Он и вправду нативный, без подлежащих либ или врапперов

E>ASN.1, Google Protocol Buffers, Boost.Serialization, s11n.net, даже мой собственный велосипед ObjESSty -- все это работает без встроенной поддержки со стороны языка.

Нууууууууу...это все не то. АСН.1 требует предварительного описания, к примеру
Re[3]: Сериализация и языки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.11.08 11:24
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

E>>По имеющимся у меня сведениям, GDC приказал долго жить. А его разработчик подключился к разработке комплятора D на основе LLVM.

G>LLVM только для 2.хх будет ?

Пока он делается только для 1.*, поддержка 2.0 в нем пока экспериментальная. Что и не удивительно, т.к. какой-либо законченой спецификации D 2.0 пока нет.

E>>Ну ей богу, зло берет по 10 раз все это объяснять. В 2.* появилась транзитивная константность. Все. Любой старый D-шный код, который хочет получить существенные преимущества от D 2.* (за счет иммутабельности, например), должен быть не просто переписан, а перепроектирован.

G>Ключевое слово — "который хочет". Если надо просто перенести ( чтоб собиралось и работало ) — то это несложно

Как раз в моем случае "который хочет".

E>>А DFL, насколько я помню, всего лишь биндинг к FLTK.

G>DFL, the D Forms Library, is an easy to use user interface toolkit for the D programming language. It brings you a high level, easy to use interface, abstracted from the native API.
G>Он и вправду нативный, без подлежащих либ или врапперов

Да, это я с FLTKd перепутал.

E>>ASN.1, Google Protocol Buffers, Boost.Serialization, s11n.net, даже мой собственный велосипед ObjESSty -- все это работает без встроенной поддержки со стороны языка.

G>Нууууууууу...это все не то. АСН.1 требует предварительного описания, к примеру

Нууууууу... Я вообще не представляю, как можно делать нормальную сериализацию без внешних описаний


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Сериализация и языки
От: gandalfgrey  
Дата: 24.11.08 11:30
Оценка:
Здравствуйте, eao197, Вы писали:

E>Пока он делается только для 1.*, поддержка 2.0 в нем пока экспериментальная. Что и не удивительно, т.к. какой-либо законченой спецификации D 2.0 пока нет.

Есть еще OpenD. Или он тоже окуклился ?

E>Как раз в моем случае "который хочет".

Ну, тогда — да, надо думать головным мозгом над архитектурой.

E>Нууууууу... Я вообще не представляю, как можно делать нормальную сериализацию без внешних описаний

Автоматически хотелось бы ! Весь вопрос в том, как быть, ежели наборы типов в момент сериализации и десериализации — разные.
Re[5]: Сериализация и языки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.11.08 11:40
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

E>>Пока он делается только для 1.*, поддержка 2.0 в нем пока экспериментальная. Что и не удивительно, т.к. какой-либо законченой спецификации D 2.0 пока нет.

G>Есть еще OpenD. Или он тоже окуклился ?

Если речь об этом: http://www.opend.org/ и об этом http://sourceforge.net/projects/brightd то, похоже, что почил еще в 2002.

E>>Как раз в моем случае "который хочет".

G>Ну, тогда — да, надо думать головным мозгом над архитектурой.

Ну так в том-то и дело. Причем, если бы константность не была транзитивной, то проблем с переносом кода из D 1.* в D 2.* лично у меня было бы гораздо меньше.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Сериализация и языки
От: gandalfgrey  
Дата: 24.11.08 11:46
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ну так в том-то и дело. Причем, если бы константность не была транзитивной, то проблем с переносом кода из D 1.* в D 2.* лично у меня было бы гораздо меньше.

При БОЛЬШОМ желании это можно обьехать, но код становится некузявым. Да и рукописной работы непропорционально много
Re[5]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.11.08 20:41
Оценка: :)
Здравствуйте, gandalfgrey, Вы писали:

E>>Нууууууу... Я вообще не представляю, как можно делать нормальную сериализацию без внешних описаний

G>Автоматически хотелось бы ! Весь вопрос в том, как быть, ежели наборы типов в момент сериализации и десериализации — разные.

А как быть, если с одной стороны 2x2=?, а с другой — ?=78, ы? Вот так же и здесь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: Сериализация и языки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 25.11.08 07:47
Оценка: 12 (1) :)
Здравствуйте, Геннадий Васильев, Вы писали:

E>>>Нууууууу... Я вообще не представляю, как можно делать нормальную сериализацию без внешних описаний

G>>Автоматически хотелось бы ! Весь вопрос в том, как быть, ежели наборы типов в момент сериализации и десериализации — разные.

ГВ>А как быть, если с одной стороны 2x2=?, а с другой — ?=78, ы? Вот так же и здесь.


У динамически-типизированных языков здесь есть преимущество перед статически-типизированными. Если в сериализованном представлении есть метки типов, то возможно восстановление данных без особых проблем. Например, пусть в сериализованном представлении у нас есть что-то вроде:
01 -- тип данных Array
03 -- его длина в элементах.
 -- Начинаются элементы массива.
 02 -- тип данных Symbol или Atom (в зависимости от языка).
 05 -- его длина.
   48 45 4C 4C 4F -- Hello -- его значение.
 03 -- тип данных Integer.
 01 -- его длина.
   10 -- его значение.
 04 -- тип данных String.
 03 -- его длина.
   42 79 65 -- Bye -- его значение.

то десериализатор в динамически-типизированном языке (вроде Ruby, Python или Erlang) сможет вернуть полностью восстановленный объект. Что-то вроде:
irb(main):007:0> data = deserialize(stream)
=> [:HELLO, 22, "Bye"]
irb(main):008:0> str = data[2]
=> "Bye"

Если программу интересует только третий элемент из массива, то этот элемент может быть легко извлечен и обработан. Как я понимаю, gandalfgrey привык к подобным штукам в Erlang-е, где помимо динамической типизации есть еще и паттерн-матчинг, который позволяет легко разбираться со структурой полученных данных. Т.е. делать что-то вроде:
process_data({_,_,S}) -> ...какая-то обработка...
process_data(_) -> ...обработка неподходящих по формату данных...

receive_and_process_data(source) ->
  S = receive_data(source),
  D = deserialize_data(S),
  process_data(D).


В статически-типизированном языке такие фокусы просто-так не получатся. Нужно будет манипулировать какими-то векторами Variant-ов или чем-то в этом духе. Но и это становится практически невозможным, если сериализация поддерживает ООП, т.е. когда можно сериализовать объект и десериализовать его на другой стороне. Причем здесь нужно поддерживать несколько специфических ситуаций:
— на принимающей стороне состав полей объекта может отличаться от состава полей на сериализующей стороне;
— на принимающей стороне может быть неизвестен тип объекта, который был сериализован.

Обработка этих ситуаций требует дополнительных описаний для подсистемы сериализации/десериализации. Именно поэтому средства сериализации с более-менее серьезными возможностями (ASN.1, Google ProtoBuf, ObjESSty) требуют внешнего описания структуры сериализуемых данных.

И еще один важный аспект. Наличие внешних описаний структуры сериализуемых данных позволяет достигать высокой компактности сериализованного представления за счет:
1) отсутствия в сериализованном потоке полей-маркеров типа поля и его длины. Так, показаный выше пример без маркеров может выглядеть так:
03 -- Длина массива в элементах.
 -- Начинаются элементы массива.
 05 -- Длина первого элемента.
   48 45 4C 4C 4F -- Hello -- его значение.
 10 -- Второй элемент.
 03 -- Длина третьего элемента.
   42 79 65 -- Bye -- его значение.

т.е. 12 байт вместо 17.
2) некоторые значения полей могут опускаться и не сохраняться в сериализованном представлении, если они имеют одно из стандартных значений. Например, если поле Handshaking::CompressionAlgorithm в большинстве случаев имеет значение "ZLib", то его можно вообще не сериализовать.
3) ASN.1 в PER-кодировке идет еще дальше -- он позволяет производить битовую упаковку. Т.е. если какое-то поле принимает значения в диапазоне 0..6, то для представления этого поля будут заняты всего-лишь три бита.

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

PS. Гена, писал вроде ответ тебе, а получился ответ для gandalfgrey


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.08 09:08
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>PS. Гена, писал вроде ответ тебе, а получился ответ для gandalfgrey


Что-то я не совсем понял, о чём ты сейчас. Я как раз и предполагаю, что структуры данных должны быть предварительно описаны на обоих сторонах канала. Если полученный пакет не удовлетворяет ожидаемому формату (длина отличается, CRC не совпадает, какого-нибудь маркера в нужном месте не оказалось, ещё что-то), то считаем его просто ошибкой передачи — и всё. Какие ещё неожиданно взявшиеся структуры объектов? Зачем?

Да собственно говоря, никаких самоописаний не бывает в природе. Если уж данные содержат некие метаданные, содержащие "описание структуры", то это как минимум означает, что приёмник имеет в своём распоряжении некую программу, которая строит по известным ей маркерам "объект" или "структуру", или "именованный список", называйте, как хотите. Дальше вопрос только в необходимой детализации этой маркировки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: Кстати
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.08 09:16
Оценка: -2
Здравствуйте, eao197, Вы писали:

process_data({_,_,S}) -> ...какая-то обработка...
process_data(_) -> ...обработка неподходящих по формату данных...


Если ты хотел узнать об одном из источников "тормозов" динамических языков, то это был он.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: Сериализация и языки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 25.11.08 09:31
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

E>>PS. Гена, писал вроде ответ тебе, а получился ответ для gandalfgrey


ГВ>Что-то я не совсем понял, о чём ты сейчас. Я как раз и предполагаю, что структуры данных должны быть предварительно описаны на обоих сторонах канала. Если полученный пакет не удовлетворяет ожидаемому формату (длина отличается, CRC не совпадает, какого-нибудь маркера в нужном месте не оказалось, ещё что-то), то считаем его просто ошибкой передачи — и всё. Какие ещё неожиданно взявшиеся структуры объектов? Зачем?


В том-то и дело, что в динамических языках это знание может быть существенно другим, чем в статически-типизированном языке. Если убрать из рассмотрения CRC, то динамический язык менее требователен к структурам данных. Ну, допустим, пишем мы сервер какой-нибудь on-line игры (пример с потолка, никогда это не писал ). И решаем, что будем отдавать на запрос статуса игрока набор их [имя, количество очков, уровень жизни, уровень мастерства, расположение на карте]. Клиент знает только этот набор, но может не знать даже какими типами данных представлены элементы в этом наборе. Имя -- это строка, атом или структура? Уровень жизни -- это Fixnum или Float? Расположение на карте -- это (X, Y, Z) или (X, Y, Time), или (X, Y, Z, Time)?

А по большому счету для динамически-типизированного языка это без разницы. Поскольку он позволяет легко все это переваривать:
player_data = deserialize(data)
name = player_data[ 0 ]
position = player_data[ 4 ]
puts "player #{name} is on #{position}"

Все будет работать

ГВ>Да собственно говоря, никаких самоописаний не бывает в природе.


ASN.1 BER (он же TLV -- Tag-Length-Value) или s-expressions, или XML -- практически самоописания данных.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: Сериализация и языки
От: gandalfgrey  
Дата: 25.11.08 10:07
Оценка:
Здравствуйте, eao197, Вы писали:

E>то десериализатор в динамически-типизированном языке (вроде Ruby, Python или Erlang) сможет вернуть полностью восстановленный объект.

В том-то и дело !

T={crysis,[{salary,low},{employers,10},{panic,yes}],2008}.

B=term_to_binary(T).

B.
<<131,104,3,100,0,6,99,114,121,115,105,115,108,0,0,0,3,104,2,100,0,6,115,97,
  108,97,114,121,100,...>>

binary_to_term(B).
{crysis,[{salary,low},{employers,10},{panic,yes}],2008}

Хотелось бы такого же и в статически-типизированных языках. ( Я понимаю, что это малореально... )

E>И еще один важный аспект. Наличие внешних описаний структуры сериализуемых данных позволяет достигать высокой компактности сериализованного представления за счет:

Разница есть, но она не очень значительна ( кроме особых случаев ). Обычно приемлемы даже текстовые форматы передачи данных, типа JSON.

E>3) ASN.1 в PER-кодировке идет еще дальше -- он позволяет производить битовую упаковку. Т.е. если какое-то поле принимает значения в диапазоне 0..6, то для представления этого поля будут заняты всего-лишь три бита.

GZIP тоже позволяет обжать поток, если порции не слишком маленькие

E>Ну и по внешним описаниям могут быть сгенерированные специализированные сериализаторы/десериализаторы, которые будут работать намного быстрее поэлементного разбора входного потока с анализом типа и размера очередного элемента, создания под него соответствующего объекта и пр.

Дык ить ! Они будут опять-таки статическими, эти сериализаторы. А как быть, ежели мне надо во время работы софта передать новый тип данных ? Сначала передать описание ? А потом что, после того, как я сгенерирую десериализатор на принимающей стороне ? Он вернет мне значение одного и только одного типа, которое будет представлять собой некий сложный контейнер с данными. Тем самым типизация как бы замыливается.

E>PS. Гена, писал вроде ответ тебе, а получился ответ для gandalfgrey

Как бы да !

Вот подумал — может, это вообще некорректная формулировка проблемы ? Уж не противоестественное ли это желание — требовать от некоего языка, чтоб он по щелчку пальцев менял свою жесткость, форму и цвет ? 8)))))
Re[8]: Сериализация и языки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 25.11.08 10:38
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

G>Хотелось бы такого же и в статически-типизированных языках. ( Я понимаю, что это малореально... )


Малореально.

E>>И еще один важный аспект. Наличие внешних описаний структуры сериализуемых данных позволяет достигать высокой компактности сериализованного представления за счет:

G>Разница есть, но она не очень значительна ( кроме особых случаев ). Обычно приемлемы даже текстовые форматы передачи данных, типа JSON.

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

E>>3) ASN.1 в PER-кодировке идет еще дальше -- он позволяет производить битовую упаковку. Т.е. если какое-то поле принимает значения в диапазоне 0..6, то для представления этого поля будут заняты всего-лишь три бита.

G>GZIP тоже позволяет обжать поток, если порции не слишком маленькие

Опять же от задачи зависит. У меня в некоторых случаях использование GZip снижало пропускную способность вдвое, при серьезной нагрузке на CPU.

E>>Ну и по внешним описаниям могут быть сгенерированные специализированные сериализаторы/десериализаторы, которые будут работать намного быстрее поэлементного разбора входного потока с анализом типа и размера очередного элемента, создания под него соответствующего объекта и пр.

G>Дык ить ! Они будут опять-таки статическими, эти сериализаторы. А как быть, ежели мне надо во время работы софта передать новый тип данных ? Сначала передать описание ? А потом что, после того, как я сгенерирую десериализатор на принимающей стороне ? Он вернет мне значение одного и только одного типа, которое будет представлять собой некий сложный контейнер с данными. Тем самым типизация как бы замыливается.

Так здесь другой вопрос возникает: ну передаст узел A узлу B новые данные, структуру которых B не знает. И что B будет с ними делать? Не зная структуру и смысл значений из все равно не обработать. Поэтому, если обновляется структура информации, то это сопровождается и обновлением софта на узлах A и B.

Есть, однако, маленький частный случай, когда B является всего лишь промежуточным звеном между A и C. В этом случае B должен уметь брать новые данные от A и отдавать их C без потери чего-либо. Для таких случаев могут быть частные решения. Я у себя сделал такое понятие, как subclassing by extension: т.е. узлы A, B и C должны знать про некий базовый тип Base. Далее узлы A и C могут делать от него любое количество наследников, о которых B даже не будет знать. Эти наследники специальным образом помечаются. Благодоря этому, при их сериализации значения специальным образом упаковываются. Узел B при десериализации понимает, что он получил объек-наследник Base, хотя и не знает его структуры. То, что B не знает, специальным образом сохраняется при десериализации и восстанавливается при новой сериализации. Поэтому B может легко ретранслировать данные между A и C, о которых он не знает.

G>Вот подумал — может, это вообще некорректная формулировка проблемы ? Уж не противоестественное ли это желание — требовать от некоего языка, чтоб он по щелчку пальцев менял свою жесткость, форму и цвет ? 8)))))


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.08 10:47
Оценка: +1
Здравствуйте, eao197, Вы писали:

ГВ>>Что-то я не совсем понял, о чём ты сейчас. Я как раз и предполагаю, что структуры данных должны быть предварительно описаны на обоих сторонах канала. Если полученный пакет не удовлетворяет ожидаемому формату (длина отличается, CRC не совпадает, какого-нибудь маркера в нужном месте не оказалось, ещё что-то), то считаем его просто ошибкой передачи — и всё. Какие ещё неожиданно взявшиеся структуры объектов? Зачем?


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


Для статически типизированного языка эта требовательность просто переносится на уровень протокола. Можно ослабить требования, можно усилить.

E>Ну, допустим, пишем мы сервер какой-нибудь on-line игры (пример с потолка, никогда это не писал ). И решаем, что будем отдавать на запрос статуса игрока набор их [имя, количество очков, уровень жизни, уровень мастерства, расположение на карте]. Клиент знает только этот набор, но может не знать даже какими типами данных представлены элементы в этом наборе. [...]


На таком уровне несложно абстрагироваться и в статически типизируемом языке. Передавай строку — да и всё. Натрави зиппер, он её ещё и ужмёт. В сущности, это простейшая ситуация. Гораздо интересней, например, если нужно сообразить — имя это "Name", "ActorName", или "ActorPublicAlias"?

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

ГВ>>Да собственно говоря, никаких самоописаний не бывает в природе.


E>ASN.1 BER (он же TLV -- Tag-Length-Value) или s-expressions, или XML -- практически самоописания данных.


А если приёмник не умеет парсить ASN или XML?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.08 10:51
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

E>>И еще один важный аспект. Наличие внешних описаний структуры сериализуемых данных позволяет достигать высокой компактности сериализованного представления за счет:

G>Разница есть, но она не очень значительна ( кроме особых случаев ). Обычно приемлемы даже текстовые форматы передачи данных, типа JSON.

Это бабушка надвое сказала.

E>>3) ASN.1 в PER-кодировке идет еще дальше -- он позволяет производить битовую упаковку. Т.е. если какое-то поле принимает значения в диапазоне 0..6, то для представления этого поля будут заняты всего-лишь три бита.

G>GZIP тоже позволяет обжать поток, если порции не слишком маленькие

+1

E>>Ну и по внешним описаниям могут быть сгенерированные специализированные сериализаторы/десериализаторы, которые будут работать намного быстрее поэлементного разбора входного потока с анализом типа и размера очередного элемента, создания под него соответствующего объекта и пр.

G>Дык ить ! Они будут опять-таки статическими, эти сериализаторы. А как быть, ежели мне надо во время работы софта передать новый тип данных ? Сначала передать описание ? А потом что, после того, как я сгенерирую десериализатор на принимающей стороне ? Он вернет мне значение одного и только одного типа, которое будет представлять собой некий сложный контейнер с данными. Тем самым типизация как бы замыливается.

Не-а. Вслед за генерацией нового десериализатора нужно ответить на вопрос: а зачем он здесь нужен? Сгенерил ты десериализатор, что ты с ним дальше намерен делать? Ладно, десериализовал данные. Куда их теперь девать?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: Сериализация и языки
От: Gluk_Kazan  
Дата: 25.11.08 11:18
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

G>Дык ить ! Они будут опять-таки статическими, эти сериализаторы. А как быть, ежели мне надо во время работы софта передать новый тип данных ? Сначала передать описание ?


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

Хорошая по своему книжка
Re[9]: Сериализация и языки
От: gandalfgrey  
Дата: 25.11.08 12:07
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ну это сильно от задачи зависит. Когда речь зайдет о сериализации/десериализации сотен тысяч значений в секунду, в дело вступят и маленький размер, и двоичное представление.

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

E>Опять же от задачи зависит. У меня в некоторых случаях использование GZip снижало пропускную способность вдвое, при серьезной нагрузке на CPU.

Скорее всего, словарь ГЗИПа был слишком большой. Опция -1 уменьшает его размер и весьма ускоряет пожатие.

E>Так здесь другой вопрос возникает: ну передаст узел A узлу B новые данные, структуру которых B не знает. И что B будет с ними делать? Не зная структуру и смысл значений из все равно не обработать. Поэтому, если обновляется структура информации, то это сопровождается и обновлением софта на узлах A и B.

Тут я вижу 2 пути :
— можно использовать некие встроенные знания на узле В о том, как интерпретировать пришедшие данные в пределах понимания узлом В их структуры. Это не всегда применимо и несколько ограничено
— можно опционально передавать и алгоритмы для обработки пришедших данных


calc_mid(L)->calc_mid(L,fun(X)->abs(X) end).

calc_mid([],_)->0;
calc_mid(L,F)->
    lists:foldl(fun(X,A)->A+F(X) end,0,L)/ length(L).

------------------------------------------
calc_mid([1,3,4.2,6]).
работает

calc_mid([{3.1,5},{-2,0},{5.5,2}],fun({X,Y})->math:sqrt(X*X+Y*Y) end).
тоже работает

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


E>Есть, однако, маленький частный случай, когда B является всего лишь промежуточным звеном между A и C. В этом случае B должен уметь брать новые данные от A и отдавать их C без потери чего-либо. Для таких случаев могут быть частные решения. Я у себя сделал такое понятие, как subclassing by extension: т.е. узлы A, B и C должны знать про некий базовый тип Base. Далее узлы A и C могут делать от него любое количество наследников, о которых B даже не будет знать. Эти наследники специальным образом помечаются. Благодоря этому, при их сериализации значения специальным образом упаковываются. Узел B при десериализации понимает, что он получил объек-наследник Base, хотя и не знает его структуры. То, что B не знает, специальным образом сохраняется при десериализации и восстанавливается при новой сериализации. Поэтому B может легко ретранслировать данные между A и C, о которых он не знает.

Это ОЧЕНЬ ограниченный случай, как мне кажется

E>Некорректная. У каждого семейства языков есть свой набор правил и идиом, с которыми нужно смирится и воспринимать их как данность. В общем -- в каждом монастыре, свой устав и со своим туда лучше не лезть

Дык хочется же ! Причем и того, и того одновременно ( таблеток от жадности тоже... ) 8)))))
Re[9]: Сериализация и языки
От: gandalfgrey  
Дата: 25.11.08 12:09
Оценка:
Здравствуйте, Gluk_Kazan, Вы писали:

G_K>Была такая древняя книжка

G_K>Название которой не соответсвовало содержанию. В ней говорилось о том как передать
G_K>новый класс на клиентскую сторону в форме потока байт-кодов, загрузить и
G_K>выполнить с целью организации распределенных вычислений

Я так понимаю, что там исключительно о Жабовской специфике ? Или там есть некие языконезависимые идеи ?
Re[10]: Сериализация и языки
От: Gluk_Kazan  
Дата: 25.11.08 13:27
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

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


G_K>>Была такая древняя книжка

G_K>>Название которой не соответсвовало содержанию. В ней говорилось о том как передать
G_K>>новый класс на клиентскую сторону в форме потока байт-кодов, загрузить и
G_K>>выполнить с целью организации распределенных вычислений

G>Я так понимаю, что там исключительно о Жабовской специфике ? Или там есть некие языконезависимые идеи ?


Исключительно языкозависимые. Но книжка по тому времени — пионерская
Re[10]: Сериализация и языки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 25.11.08 13:31
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>То есть, понимаешь, в чём парадокс. Если структура данных определена, то тип, используемый для кодирования одного элемента не особо важен с любой точки зрения. А если структура предполагается быть неопределённой, то всплывает такая куча вопросв, что сразу становится понятным, что её лучше определить и как следствие — вернуться к малозначимости вопроса о типе, кодирующем "элементарную ячейку". То есть так или иначе, но приходится возвращаться к тому или иному виду предварительного согласования структур данных, используемых дляобмена информацией.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.08 13:40
Оценка: +3 :)
Здравствуйте, gandalfgrey, Вы писали:

E>>Так здесь другой вопрос возникает: ну передаст узел A узлу B новые данные, структуру которых B не знает. И что B будет с ними делать? Не зная структуру и смысл значений из все равно не обработать. Поэтому, если обновляется структура информации, то это сопровождается и обновлением софта на узлах A и B.

G>Тут я вижу 2 пути :
G>- можно использовать некие встроенные знания на узле В о том, как интерпретировать пришедшие данные в пределах понимания узлом В их структуры. Это не всегда применимо и несколько ограничено
G>- можно опционально передавать и алгоритмы для обработки пришедших данных

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

А делов-то было: версию протокола согласовать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Сериализация и языки
От: gandalfgrey  
Дата: 25.11.08 14:10
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Пое-еха-али... И вслед за этим программа плавно выворачивается наизнанку с полной потерей зависимостей и ответа на вопрос, кто на ком стоял. Алгоритмы обработки расширяются, вводится метаметаотображение для метаотображения, метаязык для метаметаотображений, и прочие кибенематические приёмы.

Ничего такого особенно замороченного в этом нет. Получается плавная подстройка обработки данных — так это и правильно. Отдаем данные и говорим : а сделай-ка с ними нечто вот таким образом. Каким конкретно образом — тоже передаем, если та сторона этого еще не знает.
Можно, конечно, обозвать это метатрансформацией — но нужно ли ?

ГВ>А делов-то было: версию протокола согласовать.

Какую-такую версию ? Ежели мы эти версии порождаем в рантайме, кто их согласовывать будет ? Сам код ?
Тогда придется приделать ему какие-то эвристики, что ли ... Не нравится мне такая мысль. Сложно как-то
Re[12]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.11.08 14:50
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

G>Ничего такого особенно замороченного в этом нет. Получается плавная подстройка обработки данных — так это и правильно. Отдаем данные и говорим : а сделай-ка с ними нечто вот таким образом. Каким конкретно образом — тоже передаем, если та сторона этого еще не знает.


Главный вопрос: а чем эта подстройка нужна принимающей стороне?

G>Тогда придется приделать ему какие-то эвристики, что ли ... Не нравится мне такая мысль. Сложно как-то


Тепло, тепло...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[10]: Сериализация и языки
От: Erop Россия  
Дата: 25.11.08 17:48
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

G>- можно опционально передавать и алгоритмы для обработки пришедших данных


G>

G>calc_mid(L)->calc_mid(L,fun(X)->abs(X) end).

G>calc_mid([],_)->0;
G>calc_mid(L,F)->
G>    lists:foldl(fun(X,A)->A+F(X) end,0,L)/ length(L).

G>------------------------------------------
G>calc_mid([1,3,4.2,6]).
G>работает

G>calc_mid([{3.1,5},{-2,0},{5.5,2}],fun({X,Y})->math:sqrt(X*X+Y*Y) end).
G>тоже работает

G>

G>В данном случае у нас будет приходить список значений, а для второго случая еще и алгоритм, по которому считать.
G>Может показаться, что это близко к горячей замене кода, но это совсем не так.

Строго говоря, если ты умеешь передавать алгоритмы обработки данных, то ты можешь передаватьи алгоритмы сериализации, как частный случай
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Сериализация и языки
От: Erop Россия  
Дата: 25.11.08 17:50
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>А делов-то было: версию протокола согласовать.

G>Какую-такую версию ? Ежели мы эти версии порождаем в рантайме, кто их согласовывать будет ? Сам код ?
G>Тогда придется приделать ему какие-то эвристики, что ли ... Не нравится мне такая мысль. Сложно как-то

А зачем порождать типы в рантайме? Можно просто с некими универсальными описаниями работать. В зависимости от конкретной азадачи подобное представление обычно довольно легко породить. Только это уже не будет статически типизированным языком, вообще-то...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: Сериализация и языки
От: gandalfgrey  
Дата: 26.11.08 07:45
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Главный вопрос: а чем эта подстройка нужна принимающей стороне?

Это как раз — странный вопрос ! Ибо — как же иначе правильно обработать входной набор данных, о предназначении которого принимающая сторона может только догадываться ( в случае эвристик ) или не иметь никакого понятия ( в других случаях ). Есть еще вариант, когда без пришедшего извне алгоритма обрабатываем по умолчанию, в соответствии с некоей общностью, к которой принадлежит входная структура, а приходящий алгоритм служит для модификации базовой логики.

ГВ>Тепло, тепло...

Потому и пишу — сложноват такой подход, причем неоправданно. Предыдущий абзац описывает куда более простое решение ( на мой взгляд )
Re[11]: Сериализация и языки
От: gandalfgrey  
Дата: 26.11.08 07:47
Оценка:
Здравствуйте, Erop, Вы писали:

E>Строго говоря, если ты умеешь передавать алгоритмы обработки данных, то ты можешь передаватьи алгоритмы сериализации, как частный случай

Можно и так — но зачем, ежели сериализация и так поддерживает произвольные структуры данных и комбинации структур и алгоритмов ?
Re[13]: Сериализация и языки
От: gandalfgrey  
Дата: 26.11.08 07:52
Оценка: :))
Здравствуйте, Erop, Вы писали:

E>А зачем порождать типы в рантайме? Можно просто с некими универсальными описаниями работать. В зависимости от конкретной азадачи подобное представление обычно довольно легко породить. Только это уже не будет статически типизированным языком, вообще-то...


По поводу универсальных описаний : ежели потребности задачи выйдут за пределы допустимого этими описаниями ? Ситуация, когда на каждый чих правится и согласуется не только затронутый этим чихом блок, но и прилегающие к нему — некошерна. Гораздо лучше, когда , к примеру, протокол заведомо пропустит все, что я отправлю с передающей стороны — тогда все модификации будут в чисто предметной области, и не затронут ничего вспомогательно-служебного
Re[14]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.11.08 09:18
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Главный вопрос: а чем эта подстройка нужна принимающей стороне?

G>Это как раз — странный вопрос ! Ибо — как же иначе правильно обработать входной набор данных, о предназначении которого принимающая сторона может только догадываться ( в случае эвристик ) или не иметь никакого понятия ( в других случаях ).

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

И если уж возникает необходимость изменить форматы передаваемых данных, то такая возможность резервируется простым и неоригинальным способом: версией протокола, которую обменивающиеся стороны согласуют в самом начале обмена. И никаких особых эвристик не требуется: если согласована версия 3.74, то структура X сообщения Y имеет вид {int32, int32, int32}, а если версия 3.98 и выше — то {int32, double64, MCBS-string}.

G>Есть еще вариант, когда без пришедшего извне алгоритма обрабатываем по умолчанию, в соответствии с некоей общностью, к которой принадлежит входная структура, а приходящий алгоритм служит для модификации базовой логики.


Можно, но тогда ты заранее предусматриваешь возможность принять исполняемый код. Перебрасывается при этом исполняемый фрагмент (S-выражение, байт-код, бинарник, большой зип исходников для отдельно стоящего компилятора — не важно), спецификация которого точно известна; этот фрагмент встраивается в заранее условленное место по заранее определённой процедуре; система сигналит (или подразумевается, что сигналит) о его встраивании и общающиеся стороны принимают во внимание сей благой факт. Но с потолка ничего не берётся: возможность такой передачи и допустимые спецификации определяются заранее самой принимающей системой.

ГВ>>Тепло, тепло...

G>Потому и пишу — сложноват такой подход, причем неоправданно. Предыдущий абзац описывает куда более простое решение ( на мой взгляд )

Естественно — подход, подразумевающий изменчивость форматов данных сложноват. ИМХО, здесь чем проще и определённей, тем лучше.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Сериализация и языки
От: Mamut Швеция http://dmitriid.com
Дата: 26.11.08 10:25
Оценка:
E>Так я это ни разу и не оспариваю. Просто говорю, что в случае с динамическими языками согласований нужно меньше, как и возни с парсингом/преобразованием типов. Хорошо это или плохо, нужно использовать и где/когда -- это уже другие вопросы.


А ишшо если паттерн-матчинг есть, то мммм...



dmitriid.comGitHubLinkedIn
Re[15]: Сериализация и языки
От: gandalfgrey  
Дата: 26.11.08 11:14
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Правильно-правильно. А проще — урезать формат данных до такого вида, который не требует вообще никаких эвристик для своего распознавания. За исключением простейшей верификации. Просто, понятно, не требует ИИ по любому поводу.

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

ГВ>И если уж возникает необходимость изменить форматы передаваемых данных, то такая возможность резервируется простым и неоригинальным способом: версией протокола, которую обменивающиеся стороны согласуют в самом начале обмена. И никаких особых эвристик не требуется: если согласована версия 3.74, то структура X сообщения Y имеет вид {int32, int32, int32}, а если версия 3.98 и выше — то {int32, double64, MCBS-string}.

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

ГВ>Можно, но тогда ты заранее предусматриваешь возможность принять исполняемый код. Перебрасывается при этом исполняемый фрагмент (S-выражение, байт-код, бинарник, большой зип исходников для отдельно стоящего компилятора — не важно), спецификация которого точно известна; этот фрагмент встраивается в заранее условленное место по заранее определённой процедуре; система сигналит (или подразумевается, что сигналит) о его встраивании и общающиеся стороны принимают во внимание сей благой факт. Но с потолка ничего не берётся: возможность такой передачи и допустимые спецификации определяются заранее самой принимающей системой.

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

ГВ>Естественно — подход, подразумевающий изменчивость форматов данных сложноват. ИМХО, здесь чем проще и определённей, тем лучше.

Проще для кого ? Для логики, разбирающей протокольные пакеты ? Но гораздо сложнее для бизнес-логики в чреве софтины.
Кроме того, все равно рано или поздно придется менять формат данных. Так не лучше ли сразу определить, что это происходит само, без моего участия и без траты моего драгоценного времени ?
Re[16]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.11.08 13:36
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Правильно-правильно. А проще — урезать формат данных до такого вида, который не требует вообще никаких эвристик для своего распознавания. За исключением простейшей верификации. Просто, понятно, не требует ИИ по любому поводу.

G>А не выйдет. Или каждый раз опиливать надфилем по профилю, добиваясь необходимого функционального расширения ?

Разумеется — опиливать надфилем, подпаивать паяльником и доводить на шлифовальном круге.

ГВ>>И если уж возникает необходимость изменить форматы передаваемых данных, то такая возможность резервируется простым и неоригинальным способом: версией протокола, которую обменивающиеся стороны согласуют в самом начале обмена. И никаких особых эвристик не требуется: если согласована версия 3.74, то структура X сообщения Y имеет вид {int32, int32, int32}, а если версия 3.98 и выше — то {int32, double64, MCBS-string}.

G>Плохо и неприемлемо то, что в согласовании подразумевается участие человека. Человеческий труд дорог, и время реакции его велико. Не говоря уж о неизбежности ошибок.

Человек здесь ни при чём. Под "согласованием" я имею в виду handshaking протокола. "Стороны" — это приёмник и передатчик.

ГВ>>Можно, но тогда ты заранее предусматриваешь возможность принять исполняемый код. [...]

G>Разумеется, ограничения на спецификации обрабатывающего кода существуют — но они совсем не такие жесткие, как это может показаться. Ведь мы можем получить достаточно много информации о характеристиках этого кода и месте, куда бы он хотел встать, из него самого. Конечно, некие базовые знания о том, что делать с таким кодом, у системы должны быть — но именно что самые простейшие.

Чего??? От него самого??? Ага, разбежался. Вот есть указанные места — только туда и может становиться. Код только должен принести с собой идентификатор того "места", куда он собирается влезть.

ГВ>>Естественно — подход, подразумевающий изменчивость форматов данных сложноват. ИМХО, здесь чем проще и определённей, тем лучше.

G>Проще для кого ? Для логики, разбирающей протокольные пакеты ? Но гораздо сложнее для бизнес-логики в чреве софтины.

С чего это ты взял? Как раз чем меньше неопределённости — тем лучше для всех частей программы. Иной раз проще заменить программу, чем подкручивать протокол обмена данными.

G>Кроме того, все равно рано или поздно придется менять формат данных.


Пропущено одно слово: "возможно".

G>Так не лучше ли сразу определить, что это происходит само, без моего участия и без траты моего драгоценного времени ?


Сначала нужно разобраться — зачем же менять формат данных.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[17]: Сериализация и языки
От: gandalfgrey  
Дата: 26.11.08 14:04
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Разумеется — опиливать надфилем, подпаивать паяльником и доводить на шлифовальном круге.

О чем и речь

ГВ>Человек здесь ни при чём. Под "согласованием" я имею в виду handshaking протокола. "Стороны" — это приёмник и передатчик.

А это не то же самое, только другими словами ? Откуда возьмутся версии протокола ? Или их тоже будет придумывать на лету передающая сторона ( и / или принимающая ) ?

ГВ>Чего??? От него самого??? Ага, разбежался. Вот есть указанные места — только туда и может становиться. Код только должен принести с собой идентификатор того "места", куда он собирается влезть.

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

ГВ>С чего это ты взял? Как раз чем меньше неопределённости — тем лучше для всех частей программы. Иной раз проще заменить программу, чем подкручивать протокол обмена данными.

Дык, в том-то и дело ! Ну не удастся минимизировать неопределенность, не пожертвовав гибкостью и долгоживучестью.

G>>Кроме того, все равно рано или поздно придется менять формат данных.

ГВ>Пропущено одно слово: "возможно".
Возможно — с ВЕСЬМА высокой вероятностью. Если система будет развиваться, конечно

ГВ>Сначала нужно разобраться — зачем же менять формат данных.

Все просто — в старом формате невозможно представить новые данные
Re[12]: Сериализация и языки
От: Erop Россия  
Дата: 26.11.08 14:22
Оценка: 2 (2)
Здравствуйте, gandalfgrey, Вы писали:

G>Можно и так — но зачем, ежели сериализация и так поддерживает произвольные структуры данных и комбинации структур и алгоритмов ?


Затем, что данные ты передаёшь всё время, а протокол модифицируешь всё-таки редко...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: Нужны примеры...
От: Erop Россия  
Дата: 26.11.08 14:26
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

G>По поводу универсальных описаний : ежели потребности задачи выйдут за пределы допустимого этими описаниями ? Ситуация, когда на каждый чих правится и согласуется не только затронутый этим чихом блок, но и прилегающие к нему — некошерна. Гораздо лучше, когда , к примеру, протокол заведомо пропустит все, что я отправлю с передающей стороны — тогда все модификации будут в чисто предметной области, и не затронут ничего вспомогательно-служебного


IMHO нужны примеры каких-то реальных проблем и решений. А тот всё как-то непонятно.
Скажем у меня есть какая-то универсальная модель объекта. Там есть набор числовых, бинарных, перечислимых, текстовых и графических аттрибутов, а так же аттрибутов, являющихся указателями на другие объекиты. И есть ещё бинарный анрхив дополнительных данных.
Вот гоняешь ты по протоколу такие плюзи. И как оно может выйти за пределы?

С другой стороны. Если у меня есть какой-то, например С-шный код. Бизнес-сущности в нём представляются структурами. И я гоняю эти структуры через канал. Ну поменяются у меня какие-то структуры, но они же и на клиенте и на сервере поменяются тогда? А каналу вообще пофиг будет. В нём ничего вообще менять не понадобится
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.11.08 14:44
Оценка: +1
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Человек здесь ни при чём. Под "согласованием" я имею в виду handshaking протокола. "Стороны" — это приёмник и передатчик.

G>А это не то же самое, только другими словами ?

В каком-то смысле — всё вокруг одно и то же, и сегодня тот же день, что был вчера (c). Я имел в виду, что самоописание данных вполне можно заменить указанием номера версии, который сопоставляется всей группе описаний. В вычислительносм смысле такой подход может оказаться дешевле и проще, чем парсинг и анализ каждого пакета.

G>Откуда возьмутся версии протокола ? Или их тоже будет придумывать на лету передающая сторона ( и / или принимающая ) ?


Нет, разумеется. Версии протоколов придумывает человек. Человек же придумывает разные обновления для форматов и видов передаваемых данных.

ГВ>>Чего??? От него самого??? Ага, разбежался. Вот есть указанные места — только туда и может становиться. Код только должен принести с собой идентификатор того "места", куда он собирается влезть.

G>Канал мы считаем безопасным, понятное дело. И пусть уж лучше приемник решает, куда поставить жЫрную лямбду, которая и будет анализировать и трансформировать пакет для конкретного случая, чем это сделает передатчик — который может и не знать о деталях реализации приемника.

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

ГВ>>С чего это ты взял? Как раз чем меньше неопределённости — тем лучше для всех частей программы. Иной раз проще заменить программу, чем подкручивать протокол обмена данными.

G>Дык, в том-то и дело ! Ну не удастся минимизировать неопределенность, не пожертвовав гибкостью и долгоживучестью.

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

G>>>Кроме того, все равно рано или поздно придется менять формат данных.

ГВ>>Пропущено одно слово: "возможно".
G>Возможно — с ВЕСЬМА высокой вероятностью. Если система будет развиваться, конечно

Развитие совершенно не обязательно потребует поменять формат передаваемых данных. Оно ещё может потребовать добавить новые сообщения, убрать старые и т.п.

ГВ>>Сначала нужно разобраться — зачем же менять формат данных.

G>Все просто — в старом формате невозможно представить новые данные

Хех. Новые данные требуют новых программ для их обработки, не правда ли?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: Нужны примеры...
От: gandalfgrey  
Дата: 27.11.08 08:13
Оценка:
Здравствуйте, Erop, Вы писали:

E>IMHO нужны примеры каких-то реальных проблем и решений. А тот всё как-то непонятно.

E>Скажем у меня есть какая-то универсальная модель объекта. Там есть набор числовых, бинарных, перечислимых, текстовых и графических аттрибутов, а так же аттрибутов, являющихся указателями на другие объекиты. И есть ещё бинарный анрхив дополнительных данных.
E>Вот гоняешь ты по протоколу такие плюзи. И как оно может выйти за пределы?
Запросто ! Появились новые атрибуты, или новый вид представления их значений. Пример :
— данные приходили списком пар тэг / значение. Стали приходить вложенным списком, где значение может быть таким же списком. Это не предусматривалось, поэтому поддержка этого отсутствует. Как быть, куда бежать ? Затем, с ростом длины списка, стали присылать не просто список, а хэшированный словарь.
— элементарные типы данных были строки, целые числа, плавающие числа. Стало нужным передавать триплеты ( значения для 3-х фаз одного обьекта ). Куда деваться ?


E>С другой стороны. Если у меня есть какой-то, например С-шный код. Бизнес-сущности в нём представляются структурами. И я гоняю эти структуры через канал. Ну поменяются у меня какие-то структуры, но они же и на клиенте и на сервере поменяются тогда? А каналу вообще пофиг будет. В нём ничего вообще менять не понадобится

Все не так ! Все гораздо хуже ... Начнем с того, что доступ мы имеем только к клиентской части — так как серверная часть :
— находится в 120 км от ближайшего диспетчерского пункта ( телнета там нет )
— доступ к серверу оформляется через 6 бумажек и месяц ожидания
— сервер просто замурован в будку с подогревом
— и апофеоз всего — никто просто не знает, где же он находится физически
Напоминаю — телнета НЕТ. ( по причинам безопасности в основном ). Или доступ через SSH открывают по официальному запросу
Мораль — клиент меняется, сервер — нет. И как тут быть с изменением структур ?
Re[19]: Сериализация и языки
От: gandalfgrey  
Дата: 27.11.08 09:15
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>В каком-то смысле — всё вокруг одно и то же, и сегодня тот же день, что был вчера (c). Я имел в виду, что самоописание данных вполне можно заменить указанием номера версии, который сопоставляется всей группе описаний. В вычислительносм смысле такой подход может оказаться дешевле и проще, чем парсинг и анализ каждого пакета.

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

ГВ>Нет, разумеется. Версии протоколов придумывает человек. Человек же придумывает разные обновления для форматов и видов передаваемых данных.

Опять-таки : а обновление протоколов будет происходить телепатически ? Ну нет у нас доступа к серверу ! Или же он крайне затруднен

ГВ>Приёмник ничего и никогда не сможет решить, если методы "решения" ему не предписаны заранее. А если такие методы предписаны — решение переходит в тривиальную фазу. Хоть с подгрузкой программ, хоть с подгрузкой распознавателей, хоть с описанием данных. Понимаешь, о чём я? То есть снова возвращаемся к тому, что первоначально приёмник и передатчик должны располагать некоторым "описанием" передаваемых данных и способа их обработки.

Или же описанием того, как и где применять НОВЫЕ способы обработки.

ГВ>Безусловно. Вопрос в цене этой самой гибкости. Нет, я не спорю, в предельном случае может оказаться правильным вообще подгружать нужную программу по любому чиху. Но так можно дообобщаться до многого.

Что поделать ! Такова селява. Хотя, конечно, нужет какой-то баланс между крайней гибкостью и полной окостенелостью обработки пакетов.

ГВ>Развитие совершенно не обязательно потребует поменять формат передаваемых данных. Оно ещё может потребовать добавить новые сообщения, убрать старые и т.п.

А это частный случай вышеописанной ситуации. Убирать сообщения нельзя — надо сохранять совместимость, а вот добавлять часто бывает нужным. Иъ
ГВ>Хех. Новые данные требуют новых программ для их обработки, не правда ли?
Если бы так ! Народ жаждет, чтобы один и тот же софт делал ВСЕ. А так как оный народ платит денюжку, то...
Re[16]: Нужны примеры...
От: Erop Россия  
Дата: 27.11.08 10:23
Оценка: :)
Здравствуйте, gandalfgrey, Вы писали:

G>Мораль — клиент меняется, сервер — нет. И как тут быть с изменением структур ?

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

Да вас, с такой архитектурой приговорят к пожизненному расстрелу через повешенье, однозначно!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: Нужны примеры...
От: gandalfgrey  
Дата: 27.11.08 10:52
Оценка:
Здравствуйте, Erop, Вы писали:

G>>Мораль — клиент меняется, сервер — нет. И как тут быть с изменением структур ?

E>А что, возможность засунуть в этот кубокилометр бетона, куда даже потелнетиться дают только по писменному разрешению президента, так вот, засунуть в это устройство произвольный код в любой момент времени с любого клиента -- это конечно не нарушение секьюрности...
Это все же гораздо безопаснее — так как деструктивный код там выполняться не может. А если что и сдохнет в процессе выполнения — то это будет прямое следование заповедям : "Let them crash !". Конечно, тут можно придумать нехорошие варианты : например, телеуправление — но как раз ТАКИЕ вещи лучше делать максимально жесткими. К счастью, периферийное телемеханическое железо имеет очень ограниченный ассортимент

E>Да вас, с такой архитектурой приговорят к пожизненному расстрелу через повешенье, однозначно!

А куда деваться ?
Собственно, пример был с бокситового рудника. многие тысячи точек сбора данных, сотни точек управления, в том числе много критических ( подьемники, воздухоподача, водооткачка )
Re[18]: Нужны примеры...
От: Erop Россия  
Дата: 27.11.08 12:07
Оценка: +1
Здравствуйте, gandalfgrey, Вы писали:

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


Интересно, откуда в этом оборудовании может взяться неожиданный формат данных? Казалось бы, сериализуй всё в XML и не страдай гемором...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[19]: Нужны примеры...
От: gandalfgrey  
Дата: 27.11.08 12:33
Оценка:
Здравствуйте, Erop, Вы писали:

E>Интересно, откуда в этом оборудовании может взяться неожиданный формат данных? Казалось бы, сериализуй всё в XML и не страдай гемором...

Очень даже просто : добрые дядьки-КИПовцы проезжали мимо прибора, ну и решили сменить у него прошивку. Или на промежуточном сервере сбора данных потребовались вычисления, которые раньше никому нужны не были. Я уже приводил пример — считаются потери активной и реактивной мощности по фазам. Причем коэффициенты для разных фаз разные. Надо отослать туда уставки и получить обратно данные в новом формате.
Или вот вышла новая корпоративная инструкция, которая предписывает, ЧТО надо собирать для отчетности. В качестве абстрактного примера — собирать и отдавать произведение температуры прибора на частоту питающей сети с разбивкой по 15-сек интервалам на 5 минут до и после текущей точки времени.
ХМЛ — всего лишь средство представления данных, а ведь их надо еще как-то посчитать и интерпретировать
Re[19]: Нужны примеры...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.11.08 12:38
Оценка: +3
Здравствуйте, Erop, Вы писали:

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


E>Интересно, откуда в этом оборудовании может взяться неожиданный формат данных? Казалось бы, сериализуй всё в XML и не страдай гемором...


Да тут не в формате данных дело. А в том, чтобы на сервере можно было софт упдейтить когда разработчикам софта заблагорассудится. Вот, на космических зондах умудряются программы обновлять "на лету" (знаю про один случай, когда патчили Lisp-овую программу, и, кажется, на каком-то из марсианских зондах удаленно софт обновляли), поэтому людям хочется сделать это и на рудниках.

Все это выглядит попыткой найти техническое решение социальной проблемы. Если оборудование удалено и доступ к нему строго лимитирован, то у разработчиков возник соблазн: "а давайте сделаем так, чтобы нашу программу можно было патчить ни у кого не спрашивая и никому об этом не говоря". Мол, зачем разрешение на ssh-сессию испрашивать, если можно прямо в прикладном протоколе выслать новую функцию по управлению водооткачкой и не парится. Тем более, что если делать это тайком (от заказчика), то можно не проходить никаких новых приемо-сдаточных испытаний.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Нужны примеры...
От: Erop Россия  
Дата: 27.11.08 12:58
Оценка:
Здравствуйте, eao197, Вы писали:

E>Имхо, вместо того, чтобы искать хитрые способы сериализации данных для статически-типизированных языков, гораздо лучше согласовать с заказчиком процедуры удаленного обновления ПО. Чтобы заказчик четко знал, что у него может происходить, а чего не может.


+1
Мне тоже так кажется
Автор: Erop
Дата: 27.11.08
...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: Нужны примеры...
От: gandalfgrey  
Дата: 27.11.08 13:04
Оценка: 1 (1)
Здравствуйте, eao197, Вы писали:

E>Да тут не в формате данных дело. А в том, чтобы на сервере можно было софт упдейтить когда разработчикам софта заблагорассудится. Вот, на космических зондах умудряются программы обновлять "на лету" (знаю про один случай, когда патчили Lisp-овую программу, и, кажется, на каком-то из марсианских зондах удаленно софт обновляли), поэтому людям хочется сделать это и на рудниках.

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

E>Все это выглядит попыткой найти техническое решение социальной проблемы. Если оборудование удалено и доступ к нему строго лимитирован, то у разработчиков возник соблазн: "а давайте сделаем так, чтобы нашу программу можно было патчить ни у кого не спрашивая и никому об этом не говоря". Мол, зачем разрешение на ssh-сессию испрашивать, если можно прямо в прикладном протоколе выслать новую функцию по управлению водооткачкой и не парится. Тем более, что если делать это тайком (от заказчика), то можно не проходить никаких новых приемо-сдаточных испытаний.

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

E>Имхо, вместо того, чтобы искать хитрые способы сериализации данных для статически-типизированных языков, гораздо лучше согласовать с заказчиком процедуры удаленного обновления ПО. Чтобы заказчик четко знал, что у него может происходить, а чего не может.

Скажем так — потребности в этом возникают куда чаще возможностей.
А по поводу статически-типизированных языков — пока что обновляются форматы и алгоритмы для Ерланга и для навесных скриптов на Тикле. На С++ это уж слишком зловеще выглядит ( и не стоит выделки ).
Re[21]: Нужны примеры...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.11.08 13:11
Оценка: +3
Здравствуйте, gandalfgrey, Вы писали:

G>Не совсем так. Если бы дело было в одном только апдейте — то Ерланг, к примеру, предоставляет такую возможность прямо из коробки. Но все сложнее — производить горячую замену софта мало кто решится, и согласование разрешений на это — процесс не быстрый. И я их вполне могу понять : мало ли что там разработчики нацарапали, и дажн тесты не гарантируют 100 % надежности. Другое дело — когда уже работающий софт может адаптироваться ( в определенных пределах ) к изменившимся условиям и требованиям.


Смена формата представления данных в протоколе сложно назвать "определенными пределами".

G>А по поводу статически-типизированных языков — пока что обновляются форматы и алгоритмы для Ерланга и для навесных скриптов на Тикле. На С++ это уж слишком зловеще выглядит ( и не стоит выделки ).


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.11.08 17:22
Оценка: +2
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>В каком-то смысле — всё вокруг одно и то же, и сегодня тот же день, что был вчера (c). Я имел в виду, что самоописание данных вполне можно заменить указанием номера версии, который сопоставляется всей группе описаний. В вычислительносм смысле такой подход может оказаться дешевле и проще, чем парсинг и анализ каждого пакета.

G>Это дороже в организационном плане. Перепутать нумерацию версий — это просто праздник какой-то. Который случается намного чаще, чем нам хотелось бы.

Хотел спросить: "При чём тут организационная составляющая?", потом понял, что таки да — при чём.

ГВ>>Нет, разумеется. Версии протоколов придумывает человек. Человек же придумывает разные обновления для форматов и видов передаваемых данных.

G>Опять-таки : а обновление протоколов будет происходить телепатически ? Ну нет у нас доступа к серверу ! Или же он крайне затруднен

Как я понимаю, ты про эту ситуацию:

[...] серверная часть :
— находится в 120 км от ближайшего диспетчерского пункта ( телнета там нет )
— доступ к серверу оформляется через 6 бумажек и месяц ожидания
— сервер просто замурован в будку с подогревом
— и апофеоз всего — никто просто не знает, где же он находится физически
Напоминаю — телнета НЕТ. ( по причинам безопасности в основном ). Или доступ через SSH открывают по официальному запросу
Мораль — клиент меняется, сервер — нет. И как тут быть с изменением структур ?


По уму тут надо менять процедуру открытия доступа через SSH. А то у вас интересно получается — физически к серверу доступа нет, а в "электронном" смысле не то что доступ есть, а просто автострада. Скорее всего, кто-то попросту закрыл глаза на какие-то пункты инструкций, использовав, например, то, что там ничего не говорилось о возможностях Erlang. А так и инструкции "соблюдены", и софт обновляется. Если бы сервер на самом деле хотели защитить, то вам не позволили бы оставлять такие "закладки" в протоколе. Ага, это чаще всего называется именно так — закладка для неконтролируемого обновления. Если ты хотел узнать про апофеоз, то вот это он и есть на самом деле.

ГВ>>Приёмник ничего и никогда не сможет решить, если методы "решения" ему не предписаны заранее. А если такие методы предписаны — решение переходит в тривиальную фазу. Хоть с подгрузкой программ, хоть с подгрузкой распознавателей, хоть с описанием данных. Понимаешь, о чём я? То есть снова возвращаемся к тому, что первоначально приёмник и передатчик должны располагать некоторым "описанием" передаваемых данных и способа их обработки.

G>Или же описанием того, как и где применять НОВЫЕ способы обработки.

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

ГВ>>Безусловно. Вопрос в цене этой самой гибкости. Нет, я не спорю, в предельном случае может оказаться правильным вообще подгружать нужную программу по любому чиху. Но так можно дообобщаться до многого.

G>Что поделать ! Такова селява. Хотя, конечно, нужет какой-то баланс между крайней гибкостью и полной окостенелостью обработки пакетов.

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

ГВ>>Хех. Новые данные требуют новых программ для их обработки, не правда ли?

G>Если бы так ! Народ жаждет, чтобы один и тот же софт делал ВСЕ. А так как оный народ платит денюжку, то...

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

Таким образом, народ жаждет, чтобы можно было назвать ПО "одним и тем же", даже если оно сто раз переобновлено. И народ, само собой, нашёл такой способ: "новым" ПО дозволяется называть после прохождения формальной процедуры приёмки, а до того — это "неизменное ПО" с "обновляемыми сценариями", или как-то так. Вполне вероятно, что термин "обновляемый" вообще не фигурирует в документации.

Короче говоря, теперь начинается сага о терминах и их трактовках в разных контекстах, только и всего. А ты пытаешься на этом основании чуть ли не фундаментальные законы информационных технологий сотрясти.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[21]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.11.08 17:44
Оценка: +2
Здравствуйте, gandalfgrey, Вы писали:

E>>Да тут не в формате данных дело. А в том, чтобы на сервере можно было софт упдейтить когда разработчикам софта заблагорассудится. Вот, на космических зондах умудряются программы обновлять "на лету" (знаю про один случай, когда патчили Lisp-овую программу, и, кажется, на каком-то из марсианских зондах удаленно софт обновляли), поэтому людям хочется сделать это и на рудниках.

G>Не совсем так. Если бы дело было в одном только апдейте — то Ерланг, к примеру, предоставляет такую возможность прямо из коробки. Но все сложнее — производить горячую замену софта мало кто решится, и согласование разрешений на это — процесс не быстрый. И я их вполне могу понять : мало ли что там разработчики нацарапали, и дажн тесты не гарантируют 100 % надежности. Другое дело — когда уже работающий софт может адаптироваться ( в определенных пределах ) к изменившимся условиям и требованиям.

Вот-вот. Ключевое слово — процедура обновления. Сопряжённые термины: ответственность, делегирование, полномочия, допуск.

E>>Все это выглядит попыткой найти техническое решение социальной проблемы. [...]

G>Надо заметить, что стандарты на телемеханические и телеметрические протоколы предусматривают передачу алгоритмов в качестве конфигурационных данных. Но доля истины в этом утверждении есть — конечно, тайком от заказчика делать этого никто не будет — просто ему самому спокойнее, когда бинарники работают те же самые, что и год назад.

Да, да, да. Ему самому спокойнее, даже если эти бинарники уже отодвинуты в дальний угол.

E>>Имхо, вместо того, чтобы искать хитрые способы сериализации данных для статически-типизированных языков, гораздо лучше согласовать с заказчиком процедуры удаленного обновления ПО. Чтобы заказчик четко знал, что у него может происходить, а чего не может.

G>Скажем так — потребности в этом возникают куда чаще возможностей.



G>А по поводу статически-типизированных языков — пока что обновляются форматы и алгоритмы для Ерланга и для навесных скриптов на Тикле. На С++ это уж слишком зловеще выглядит ( и не стоит выделки ).


Зловеще выглядит "подгрузка исполняемого кода". А интерпертируемые скрипты — не страшно. Они ж интерпретируемые — чего их бояться-то?!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.11.08 18:31
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

E>>Интересно, откуда в этом оборудовании может взяться неожиданный формат данных? Казалось бы, сериализуй всё в XML и не страдай гемором...

G>Очень даже просто : добрые дядьки-КИПовцы проезжали мимо прибора, ну и решили сменить у него прошивку.

Оригиналы они, эти дядьки-КИПовцы. То есть они могут привести устройство в нерабочее состояние, так, что ли?

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


Ну и что? Ничего же из ниоткуда не берётся, так или иначе — сначала устаканивается сам формат данных, а прежде оного устканства появляется требование.

G>Или вот вышла новая корпоративная инструкция, которая предписывает, ЧТО надо собирать для отчетности. В качестве абстрактного примера — собирать и отдавать произведение температуры прибора на частоту питающей сети с разбивкой по 15-сек интервалам на 5 минут до и после текущей точки времени.


И что? Если приборы могут передавать эти данные — мы их собираем. Если не могут — обновляем прошивку с помощью КИПовцев. В любом случае про ожидаемое изменение форматов и набора данных известно заранее — у нас же есть корпоративная инструкция, предписывающая "научить" устройства таким фортелям.

G>ХМЛ — всего лишь средство представления данных, а ведь их надо еще как-то посчитать и интерпретировать


О том и диспут.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.11.08 18:52
Оценка: +3
Здравствуйте, gandalfgrey, Вы писали:

G>>>Мораль — клиент меняется, сервер — нет. И как тут быть с изменением структур ?

E>>А что, возможность засунуть в этот кубокилометр бетона, куда даже потелнетиться дают только по писменному разрешению президента, так вот, засунуть в это устройство произвольный код в любой момент времени с любого клиента -- это конечно не нарушение секьюрности...
G>Это все же гораздо безопаснее — так как деструктивный код там выполняться не может.

Деструктивный — это вовсе не тот, который приводит к core dump. Вернее — не только он. Например, деструктивный код может фальсифицировать данные о температуре прибора, из-за чего этот прибор будет неправильно охлаждаться. Из прибора пойдёт дым, или он покроется инеем, или выдаст кривую команду на управляющие системы. Но при этом всё пройдёт тихо и гладко с точки зрения ОС — даже мусоросборщик отработает. Так что core dump — это так, страшилка для кулхацкеров.

Так вот, то, что вам дают возможность апдейтить код, как вам вздумается (сиречь — по упрощённой процедуре) — это означает, что ответственные лица в организации-заказчике снимают (частично) с себя ответственность за подобные последствия. А фигли? Ничего деструктивного не выполняется — это программисты во всём виноваты. И вместо того, чтобы развивать содержательную часть приёмо-сдаточных испытаний — переваливают ответственность за последствия полностью на вас.

G>А если что и сдохнет в процессе выполнения — то это будет прямое следование заповедям : "Let them crash !". Конечно, тут можно придумать нехорошие варианты : например, телеуправление — но как раз ТАКИЕ вещи лучше делать максимально жесткими. К счастью, периферийное телемеханическое железо имеет очень ограниченный ассортимент


Оригинальненько так: Let them crash, особенно в контексте того, о чём ты написал ниже.

E>>Да вас, с такой архитектурой приговорят к пожизненному расстрелу через повешенье, однозначно!

G>А куда деваться ?

Работать надо, как это ни удивительно. А не надеяться на IT-шное словоблудство.

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


Для деструктивного кода поле широчайшее, к сожалению. Шире просто представить невозможно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[17]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.11.08 19:02
Оценка: :)
Здравствуйте, Erop, Вы писали:

E>Да вас, с такой архитектурой [...]


Вот вам и способ "выстрелить самому себе в ногу" на Эрланге, Лиспе и куче других языков. С++ в сравнении с ними — дитё розовощёкое.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: NB: Ещё один момент
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.11.08 19:40
Оценка:
ГВ>А фигли? Ничего деструктивного не выполняется — это программисты во всём виноваты.

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

G>>К счастью, периферийное телемеханическое железо имеет очень ограниченный ассортимент


Если я тебя правильно понял, то это многое объясняет. Например, вам может быть позволено играться, потому что сама аппаратура обладает необходимой надёжностью по параметрам управления, а способы наблюдения (сиречь — форматирование и преобразование данных наблюдений) уже не так критичны, это всего лишь плюс-минус удобство. Правду сказать, в это мне верится гораздо больше, чем в паталогический идиотизм управленцев.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[21]: Нужны примеры...
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.11.08 04:41
Оценка: +1
Здравствуйте, gandalfgrey, Вы писали:

G>Надо заметить, что стандарты на телемеханические и телеметрические протоколы предусматривают передачу алгоритмов в качестве конфигурационных данных. Но доля истины в этом утверждении есть — конечно, тайком от заказчика делать этого никто не будет — просто ему самому спокойнее, когда бинарники работают те же самые, что и год назад.

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

Если имеется в виду то, что сервер типа не изменился; стоит начать посылать на него пакеты в старом формате — и всё починится, то я не понимаю в чем принципиальная разница с удаленной перепрошивкой. Потому что с ней "стоит перепрошить на сентябрьскую версию из SVN — и всё починится".

Зато есть некоторые опасения. Грубо говоря, смена "жесткого" протокола и связанная с ней перепрошивка — операция редкая и привилегированная. Все они лежат в логе; всегда точно известно, кто когда что и на что менял. В случае per-message изменения кода, для анализа катастрофы нужен полный лог всех сообщений.

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

Как ты будешь отлавливать такие ситуации? Вроде смотрим — всё нормально; в системе — ни следа от вредоносного кода; откуда взялся запредельный параметр — невозможно понять.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Сериализация и языки
От: gandalfgrey  
Дата: 28.11.08 07:30
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>По уму тут надо менять процедуру открытия доступа через SSH. А то у вас интересно получается — физически к серверу доступа нет, а в "электронном" смысле не то что доступ есть, а просто автострада. Скорее всего, кто-то попросту закрыл глаза на какие-то пункты инструкций, использовав, например, то, что там ничего не говорилось о возможностях Erlang. А так и инструкции "соблюдены", и софт обновляется. Если бы сервер на самом деле хотели защитить, то вам не позволили бы оставлять такие "закладки" в протоколе. Ага, это чаще всего называется именно так — закладка для неконтролируемого обновления. Если ты хотел узнать про апофеоз, то вот это он и есть на самом деле.

Тут есть еще одно "НО" — а именно, рестарт системы при замене софта цивильным способом занимает много времени. Горячее обновление кода не спасает ситуацию, поскольку присутствуют и модули на Ерланге, и на С++, и на Тикле. Причем конфигурация многосерверная, что еще более замедляет подьем системы. Модуль-концентратор на С++ написан 7 лет назад, и при достаточно больших базах может стартовать несколько часов. Все это время система частично функциональна.

ГВ>Что есть частный случай известного обоим сторонам описания передаваемых данных.

Ну разумеется, в любом случае мы исходим из наших знаний о железе и процессе работы с ним. Так что можно назвать это знание ПРЕДОПРЕДЕЛЕННЫМ

ГВ>Да нет. Селява здесь в требованиях нормативных документов и технических нюансах систем программирования.

А это гораздо хуже...

ГВ>Ну опять ты за своё. Народ на самом деле жаждет на ёлку влезть... То есть он жаждет, чтобы формальные требования к процедурам соблюдались, но в то же время ПО обновлялось без особых заморочек. Менять процедуры хлопотно и лишняя ответственность, проходить их каждый раз, считай — прибить дело на корню, посему попросту обойти их — гораздо проще. Пусть даже для этого придётся назвать динамически обновляемое ПО "одной и той же версией", что может быть корректным по каким-то формальным признакам.

Вот она, сермяжно-посконная правда ! Все так и есть

ГВ>Таким образом, народ жаждет, чтобы можно было назвать ПО "одним и тем же", даже если оно сто раз переобновлено. И народ, само собой, нашёл такой способ: "новым" ПО дозволяется называть после прохождения формальной процедуры приёмки, а до того — это "неизменное ПО" с "обновляемыми сценариями", или как-то так. Вполне вероятно, что термин "обновляемый" вообще не фигурирует в документации.

А вот уже уже утрирование

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

Не, даже не помышлял такого ! И чего, собственно, революционного в передаче алгоритмов по проводам ? В любом случае, расчетные скрипты являются частью файла конфигурации. А подмена конфигурации ДОЛЖНА осуществляться без полного перезапуска системы
Re[22]: Нужны примеры...
От: gandalfgrey  
Дата: 28.11.08 07:33
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вот-вот. Ключевое слово — процедура обновления. Сопряжённые термины: ответственность, делегирование, полномочия, допуск.

Не пробовали сказать такие слова какому-либо мелкому/среднему боссу в большой корпорации ? Кивать с умным видом они, конечно, будут — но это и все !

ГВ>Да, да, да. Ему самому спокойнее, даже если эти бинарники уже отодвинуты в дальний угол.

Ежели говорить формально — то бинарники те же, что и были.

ГВ>Зловеще выглядит "подгрузка исполняемого кода". А интерпертируемые скрипты — не страшно. Они ж интерпретируемые — чего их бояться-то?!

Скрипты проще ограничить в возможностях.
Re[21]: Нужны примеры...
От: gandalfgrey  
Дата: 28.11.08 07:39
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Оригиналы они, эти дядьки-КИПовцы. То есть они могут привести устройство в нерабочее состояние, так, что ли?

Запросто ! И не раз такое делали. Вот пример : есть такой агрегат, аппаратный концентратор УСПД. Работает крайне криво, но изготовители как бы работают над этим. Присылают новые прошивки и т.д. Но ! Эти прошивки работают корректно только на определенных модификациях агрегата. Определить это можно только разглядывая печатную плату.

ГВ>Ну и что? Ничего же из ниоткуда не берётся, так или иначе — сначала устаканивается сам формат данных, а прежде оного устканства появляется требование.

Господя ! Если б это было так ! Сначала требование, причем из разряда "вынь да положь"

ГВ>И что? Если приборы могут передавать эти данные — мы их собираем. Если не могут — обновляем прошивку с помощью КИПовцев. В любом случае про ожидаемое изменение форматов и набора данных известно заранее — у нас же есть корпоративная инструкция, предписывающая "научить" устройства таким фортелям.

В большинстве случаев — значительную часть данных высчитывает микросервер, на котором висит этот прибор.
Re[19]: Нужны примеры...
От: gandalfgrey  
Дата: 28.11.08 07:49
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Деструктивный — это вовсе не тот, который приводит к core dump. Вернее — не только он. Например, деструктивный код может фальсифицировать данные о температуре прибора, из-за чего этот прибор будет неправильно охлаждаться. Из прибора пойдёт дым, или он покроется инеем, или выдаст кривую команду на управляющие системы. Но при этом всё пройдёт тихо и гладко с точки зрения ОС — даже мусоросборщик отработает. Так что core dump — это так, страшилка для кулхацкеров.

Согласен.

ГВ>Так вот, то, что вам дают возможность апдейтить код, как вам вздумается (сиречь — по упрощённой процедуре) — это означает, что ответственные лица в организации-заказчике снимают (частично) с себя ответственность за подобные последствия. А фигли? Ничего деструктивного не выполняется — это программисты во всём виноваты. И вместо того, чтобы развивать содержательную часть приёмо-сдаточных испытаний — переваливают ответственность за последствия полностью на вас.

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

ГВ>Оригинальненько так: Let them crash, особенно в контексте того, о чём ты написал ниже.

Это имеет значение "пусть лучше оно сдохнет, чем неправильно отработает"

ГВ>Работать надо, как это ни удивительно. А не надеяться на IT-шное словоблудство.

Именно, что работать. А не заниматься беспрестанными приемо-сдачами. Словоблудство никому не нужно. А нужна людям работа оборудования, непрерывная, без остановок на наладку / конфигурирование.

ГВ>Для деструктивного кода поле широчайшее, к сожалению. Шире просто представить невозможно.

Это должен быть ПРЕДНАМЕРЕННО вредоносный код
Re[18]: Нужны примеры...
От: gandalfgrey  
Дата: 28.11.08 07:52
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вот вам и способ "выстрелить самому себе в ногу" на Эрланге, Лиспе и куче других языков. С++ в сравнении с ними — дитё розовощёкое.

Жизнь показывает иное — ежели падения или отказы ( по причине некорректности кода / входных данных / чего-то еще ) модулей на С++ случаются регулярно, то Ерланговские минисервера работают. Они просто работают. Годами.
Статистика на этот счет у меня богатая, так что переубедить меня будет сложно.
Re[20]: NB: Ещё один момент
От: gandalfgrey  
Дата: 28.11.08 07:58
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>И самое главное — документы-то все в порядке. И никаких формальных нарушений — все ответственные лица ответственно выполнили свою ответственную работу с документами приёмо-сдаточных испытаний.

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

ГВ>Если я тебя правильно понял, то это многое объясняет. Например, вам может быть позволено играться, потому что сама аппаратура обладает необходимой надёжностью по параметрам управления, а способы наблюдения (сиречь — форматирование и преобразование данных наблюдений) уже не так критичны, это всего лишь плюс-минус удобство. Правду сказать, в это мне верится гораздо больше, чем в паталогический идиотизм управленцев.

Интересно, а как это предполагается принимать решение о включении / выключении чего-либо без данных о состоянии зависимых цепочек ?
И выражение "патологический идиотизм" некорректно. Это обычный корпоративный бюрократизм. Не без тупости, конечно...
Re[22]: Нужны примеры...
От: gandalfgrey  
Дата: 28.11.08 08:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Вот природу этого спокойствия хотелось бы понять поточнее.

Это во многом психологический фактор

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

Требования ВСЕХ заказчиков — подмена конфигурации без полного рестарта системы. И я их понимаю — они не хотят оставлять промплощадку без управления/диспетчеризации

S>Если имеется в виду то, что сервер типа не изменился; стоит начать посылать на него пакеты в старом формате — и всё починится, то я не понимаю в чем принципиальная разница с удаленной перепрошивкой. Потому что с ней "стоит перепрошить на сентябрьскую версию из SVN — и всё починится".

Разница во времени ответа на эти два действия

S>Зато есть некоторые опасения. Грубо говоря, смена "жесткого" протокола и связанная с ней перепрошивка — операция редкая и привилегированная. Все они лежат в логе; всегда точно известно, кто когда что и на что менял. В случае per-message изменения кода, для анализа катастрофы нужен полный лог всех сообщений.

Сама замена алгоритма по сообщению тоже всегда лежит в логе — не так часто она и происходит.

S>Типа вот сорвало у нас предохранительный клапан; почему — оказывается один из пакетов в экспериментальных целях передал некий коэффициент в виде byte, а не int; после десериализации это привело к целому переполнению при умножении, и на управляемое устройство пошёл не тот сигнал.

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

S>Как ты будешь отлавливать такие ситуации? Вроде смотрим — всё нормально; в системе — ни следа от вредоносного кода; откуда взялся запредельный параметр — невозможно понять.

телеуправление логируется на каждом шаге
Re[23]: Нужны примеры...
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.11.08 09:32
Оценка:
Здравствуйте, gandalfgrey, Вы писали:
G>Сама замена алгоритма по сообщению тоже всегда лежит в логе — не так часто она и происходит.
Не понял. Речь, вроде бы, шла о том, что в самом сообщении лежит алгоритм "обработки меня". Мы же вроде всё еще про динамическую типизацию, рвзве нет?

S>>Как ты будешь отлавливать такие ситуации? Вроде смотрим — всё нормально; в системе — ни следа от вредоносного кода; откуда взялся запредельный параметр — невозможно понять.

G>телеуправление логируется на каждом шаге
Имею некоторый скепсис насчет познаваемости таких логов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Нужны примеры...
От: gandalfgrey  
Дата: 28.11.08 09:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Не понял. Речь, вроде бы, шла о том, что в самом сообщении лежит алгоритм "обработки меня". Мы же вроде всё еще про динамическую типизацию, рвзве нет?

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

S>Имею некоторый скепсис насчет познаваемости таких логов.

Есть такое — сделать хорошее и внятное логирование — искусство.
Re[25]: Нужны примеры...
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.11.08 11:27
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

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


S>>Не понял. Речь, вроде бы, шла о том, что в самом сообщении лежит алгоритм "обработки меня". Мы же вроде всё еще про динамическую типизацию, рвзве нет?

G>Только при изменении алгоритма присходит перепосылка его, после чего он становится известным системе.
В таком случае это обычная удаленная перепрошивка, не имеющая отношния к динамической типизации. Что и с чем мы сравниваем?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Нужны примеры...
От: gandalfgrey  
Дата: 28.11.08 11:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>В таком случае это обычная удаленная перепрошивка, не имеющая отношния к динамической типизации. Что и с чем мы сравниваем?

Нет, это просто кэширование. Алгоритмы могут приходить и подряд, в каждом сообщении — но только в случае изменения оных.
Вот примерчик :

loop(Algs)->
  receive
    {Data,F}->
      F(Data),
      loop(insert_alg(Algs,get_tag(Data),F));

    {Data,{once,F}}->
      F(Data),
      loop(Algs);

    {Data}->
      F1=get_alg(Algs,get_tag(Data)),
      F1(Data),
      loop(Algs)

  end.

Как-то вот так...
В первом случае приходит пакет данных и алгоритм, который складируется в хранилище.
Во втором — однократное использование прибежавшего алгоритма
Во третьем — используется уже заскладированный из хранилища
Re[23]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.11.08 15:45
Оценка: +1
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Вот-вот. Ключевое слово — процедура обновления. Сопряжённые термины: ответственность, делегирование, полномочия, допуск.

G>Не пробовали сказать такие слова какому-либо мелкому/среднему боссу в большой корпорации ? Кивать с умным видом они, конечно, будут — но это и все !

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

ГВ>>Да, да, да. Ему самому спокойнее, даже если эти бинарники уже отодвинуты в дальний угол.

G>Ежели говорить формально — то бинарники те же, что и были.

Именно, что формально.

ГВ>>Зловеще выглядит "подгрузка исполняемого кода". А интерпертируемые скрипты — не страшно. Они ж интерпретируемые — чего их бояться-то?!

G>Скрипты проще ограничить в возможностях.

До некоторой степени. Сам понимаешь, что уязвимость системы определяется самым уязвимым звеном. Если скрипт выполняет какую-то критически важную работу, и при этом не защищён от неуправляемых обновлений, то это называется "дыркой". Пусть он даже работает в трёхслойном сандбоксе.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.11.08 16:10
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Вот вам и способ "выстрелить самому себе в ногу" на Эрланге, Лиспе и куче других языков. С++ в сравнении с ними — дитё розовощёкое.

G>Жизнь показывает иное — ежели падения или отказы ( по причине некорректности кода / входных данных / чего-то еще ) модулей на С++ случаются регулярно, то Ерланговские минисервера работают. Они просто работают. Годами.
G>Статистика на этот счет у меня богатая, так что переубедить меня будет сложно.

Let them crash?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.11.08 16:12
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Так вот, то, что вам дают возможность апдейтить код, как вам вздумается (сиречь — по упрощённой процедуре) — это означает, что ответственные лица в организации-заказчике снимают (частично) с себя ответственность за подобные последствия. А фигли? Ничего деструктивного не выполняется — это программисты во всём виноваты. И вместо того, чтобы развивать содержательную часть приёмо-сдаточных испытаний — переваливают ответственность за последствия полностью на вас.

G>Неа — ответственность лежит всегда и только на диспетчерах. Только человек может оценить ситуацию и принять решение. Например, расходомер стока воды показывает, что поток резко убыл. А потребляемая мощность автономного насоса каскадом ниже увеличилась. И что делать, эвакуировать людей с горизонта или поставить расходомер в план ремонта ?

Не, ты не понял. Диспетчер получит по ушам первым, если что пойдёт не так, но это уже критический случай. Задача руководителей — найти такие способы организации работы, чтобы снизить вероятность такого события. Я именно об этом говорил.

ГВ>>Оригинальненько так: Let them crash, особенно в контексте того, о чём ты написал ниже.

G>Это имеет значение "пусть лучше оно сдохнет, чем неправильно отработает"

Да это-то понятно.

ГВ>>Работать надо, как это ни удивительно. А не надеяться на IT-шное словоблудство.

G>Именно, что работать. А не заниматься беспрестанными приемо-сдачами. Словоблудство никому не нужно. А нужна людям работа оборудования, непрерывная, без остановок на наладку / конфигурирование.

Хех. Приёмо-сдачу устраивают не для словоблудства, а для передачи ответственности. Но это опять таки — по уму. По тому же уму, чтобы сократить количество приёмо-сдаточных мероприятий (и вообще — метаний), предварительно занимаются сбором и анализом требований, пожеланий и т.п. Но это "по уму".

ГВ>>Для деструктивного кода поле широчайшее, к сожалению. Шире просто представить невозможно.

G>Это должен быть ПРЕДНАМЕРЕННО вредоносный код

Ты не понял. Деструктивный код приводит к нарушению работы системы. Вышибанием в core dump или ошибкой округления значения температуры — не суть важно. Преднамеренность тоже не особо важна для оценки деструктивности.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.11.08 16:13
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Если бы сервер на самом деле хотели защитить, то вам не позволили бы оставлять такие "закладки" в протоколе. Ага, это чаще всего называется именно так — закладка для неконтролируемого обновления. Если ты хотел узнать про апофеоз, то вот это он и есть на самом деле.

G>Тут есть еще одно "НО" — а именно, рестарт системы при замене софта цивильным способом занимает много времени. Горячее обновление кода не спасает ситуацию, поскольку присутствуют и модули на Ерланге, и на С++, и на Тикле. Причем конфигурация многосерверная, что еще более замедляет подьем системы. Модуль-концентратор на С++ написан 7 лет назад, и при достаточно больших базах может стартовать несколько часов. Все это время система частично функциональна.

Я тебе про Фому, а ты мне про Ерёму. Технические сложности давай уж отдельно, организационные — отдельно. Я понимаю, что реальные условия обычно противоречивы и полны глупостей, но это не означает, что глупости перестают быть таковыми. В твоём случае я вижу организационную глупость, связанную с тем, что код вроде бы и нельзя обновлять, но в то же время можно. Можно называеть это корпоративным бюрократизмом, можно ещё как-то — не суть. Суть в том, что у ваших заказчиков эммм... несколько противоречивый подход к организации обновлений.

ГВ>>Что есть частный случай известного обоим сторонам описания передаваемых данных.

G>Ну разумеется, в любом случае мы исходим из наших знаний о железе и процессе работы с ним. Так что можно назвать это знание ПРЕДОПРЕДЕЛЕННЫМ

+1

ГВ>>Да нет. Селява здесь в требованиях нормативных документов и технических нюансах систем программирования.

G>А это гораздо хуже...

То-то и оно.

ГВ>>Менять процедуры хлопотно и лишняя ответственность, проходить их каждый раз, считай — прибить дело на корню, посему попросту обойти их — гораздо проще. Пусть даже для этого придётся назвать динамически обновляемое ПО "одной и той же версией", что может быть корректным по каким-то формальным признакам.

G>Вот она, сермяжно-посконная правда ! Все так и есть

Отлично, от этого и будем отталкиваться.

ГВ>>Таким образом, народ жаждет, чтобы [...]

G>А вот уже уже утрирование

Вот и хорошо. Хотя в сущности этот абзац не противоречит предыдущему.

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

G>Не, даже не помышлял такого ! И чего, собственно, революционного в передаче алгоритмов по проводам ? В любом случае, расчетные скрипты являются частью файла конфигурации. А подмена конфигурации ДОЛЖНА осуществляться без полного перезапуска системы

Ничего революционного в передаче алгоритмов по проводам нет. Революционными были твои формулировки задач на передачу алгоритмов. Я зацепился за твоё высказывание о том, что программа-де может самонастраиваться на обработку новых форматов данных и т.п. На поверку выходит, что никакой неожиданной "самонастройки" на самом деле нет — есть всё то, о чём упомянули твои оппоненты: предварительная подготовка требований, предварительная подготовка системы к самонастройке в виде "закладок", заранее согласованный протокол и т.п.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.11.08 16:14
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Оригиналы они, эти дядьки-КИПовцы. То есть они могут привести устройство в нерабочее состояние, так, что ли?

G>Запросто ! И не раз такое делали. Вот пример : есть такой агрегат, аппаратный концентратор УСПД. Работает крайне криво, но изготовители как бы работают над этим. Присылают новые прошивки и т.д. Но ! Эти прошивки работают корректно только на определенных модификациях агрегата. Определить это можно только разглядывая печатную плату.

Эх.

ГВ>>Ну и что? Ничего же из ниоткуда не берётся, так или иначе — сначала устаканивается сам формат данных, а прежде оного устканства появляется требование.

G>Господя ! Если б это было так ! Сначала требование, причем из разряда "вынь да положь"

Э-э-э... Ты пытаешься возразить? Последовательность-то, вроде, не меняется: требование, потом формат, потом реализация.

ГВ>>И что? Если приборы могут передавать эти данные — мы их собираем. Если не могут — обновляем прошивку с помощью КИПовцев. В любом случае про ожидаемое изменение форматов и набора данных известно заранее — у нас же есть корпоративная инструкция, предписывающая "научить" устройства таким фортелям.

G>В большинстве случаев — значительную часть данных высчитывает микросервер, на котором висит этот прибор.

Ну микросервер, так микросервер.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[21]: NB: Ещё один момент
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.11.08 16:22
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>И самое главное — документы-то все в порядке. И никаких формальных нарушений — все ответственные лица ответственно выполнили свою ответственную работу с документами приёмо-сдаточных испытаний.

G>Доля истины в этом есть, но только доля. Бумага и вправду прикрывает задницу, но это непрочный щит. И в случае затопления горизонта иметь будут всех, мало обращая внимания на бумажки. Потому как — денежные потери это удар по карману владельцев и топов

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

G>Интересно, а как это предполагается принимать решение о включении / выключении чего-либо без данных о состоянии зависимых цепочек ?


Это может быть реализовано либо аппаратно, либо на недоступном для обновляемого ПО уровне. Но это гипотетически, я не знаю той аппаратуры, с которой вы работаете.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: Понтяно. Вопрос: Кто же успеет полнять лимон первым?
От: Erop Россия  
Дата: 28.11.08 21:10
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

G>Требования ВСЕХ заказчиков — подмена конфигурации без полного рестарта системы. И я их понимаю — они не хотят оставлять промплощадку без управления/диспетчеризации


Всё равно не понятно зачем иметь возможность апгрейда кода прямо в процессе передачи данных?
Казалось бы, логично иметь отдельный протокол, по которому сервис конфигурится. Можно, довольно легко, сделать возможность автоматического отката, если что не так пошло, можно иметь централизованную систему управления версиями ПО и протоколов на разных станциях.
Всё это можно хорошо тестировать, логгировать и контролировать.
А описанный тобой всемогутер, который позволяет серверам непредсказуемо и неуправляемо меняться при каждой передаче структуры по каналу -- это какой-то рай для вирусописателя, IMHO.

Мой тебе совет. Напиши поверх вашего супер-пупер-апдейтера пару-тройку-десятку вирусов + вакцины. Запусти и попроси у владельцев $1e6. Для этого, IMHO, ваша архитектура более чем подходит...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[27]: Нужны примеры...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.11.08 10:49
Оценка: +1
Здравствуйте, gandalfgrey, Вы писали:

G>
G>      loop(insert_alg(Algs,get_tag(Data),F));
G>      F1=get_alg(Algs,get_tag(Data)),
G>


Ну, собственно говоря, все стало на свои места и чуда не произошло. В блоке данных явно передается неский идентификатор, который идентифицирует принадлежность данных. Т.е. протокол заранее спроектирован с поддержкой расширяемости. И реализуется расширяемость, как правило, везде однообразно -- в каждом пакете (сообщении) есть общий для всех пакетов заголовок с идентификатором и какая-то зависящая от типа пакета часть. Эта часть может называться по разному -- opaque или extension point, но суть все равно остается такой же: приемник знает, как извлечь все сообщение и как по общей части пакета определить содержимое extension point-а.

Для статически-типизированных языков в продвинутых системах сериализации это все уже давно поддерживается. Сам термин "extension points" используется в ASN.1.

Вот вы сказали, что мой механизм subclassing by extension может применяться в очень ограниченном множестве случаев. Хотя как раз для приведенного вами примера он и предназначен. Допустим, на C++ мы пакет описываем в виде базового класса:
class pdu_t : public <здесь какой-то базовый класс, навязанный системой сериализации>
  {
  public :
    pdu_t(
      // Идентификатор типа PDU.
      const pdu_type_id_t & pdu_id )
      : m_pdu_id( pdu_id )
      {}

    const pdu_type_id_t
    pdu_id() const { return m_pdu_id; }
    ...
  private :
    pdu_type_id_t m_pdu_id;
  };

От которого наследуются конкретные типы PDU:
class apply_new_factor_pdu_t : public pdu_t
  {
  public :
    float x_factor() const { ... }
    float y_factor() const { ... }
  ...
  };

class change_speed_and_acceleration_pdu_t : public pdu_t
  {
  public :
    speed_t speed() const { ... }
    acceleration_t acceleration() const { ... }
    duration_t acceleration_duration() const { ... }
  ...
  };
...

А при обработке входящих пракетов происходит десериализация PDU так, что после десериализации возвращается указатель на pdu_t:
std::auto_ptr< pdu_t > pdu( deserialize_data( in_stream ) );
pdu_processor_t * processor = get_processor( pdu->pdu_id() );
if( processor )
  processor->process( *pdu );

Где обработчики реализуют некий интерфейс pdu_processor_t:
class pdu_processor_t
  {
  public :
    virtual ~pdu_processor_t();
    virtual const pdu_type_id_t &
    pdu_id() const = 0;
    virtual void
    process( const pdu_t & pdu ) = 0;
  };

Например:
class new_factor_pdu_processor_t : public pdu_processor_t
  {
  public :
    ...
    virtual void
    process( const pdu_t & pdu )
      {
        // В принципе, здесь лучше было бы использовать dynamic_cast, но
        // в моем механизме subclassing_by_extension нельзя использовать
        // множественное наследование. Поэтому достаточно и static_cast.
        const new_factor_pdu_t & cmd = static_cast< const new_factor_pdu_t & >( pdu );
        setup_new_x_factor( cmd.x_factor() );
        setup_new_y_factor( cmd.y_factor() );
      }
  };


Выгода от использования subclassing by extension в том, что если тип данных на принимающией строне не известен, то будет десериализована только та часть объекта, которая известна принимающей стороне. В данном примере -- это базовый класс pdu_t. Программа получит pdu_id, определит, что для него нет обработчика, и соответствующим образом среагирует.

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

Обновлять алгоритмы обработки удаленно в C++ хоть и проблематично, но все-таки возможно. Например, можно готовые DLL-ки со специальной точкой входа пересылать. Удаленная сторона их сохраняет, подгружает и интегрирует в свой основной процесс. Хотя лучше это все-таки делать другими средствами, с возможностью быстрого отката к предыдущим версиям.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[24]: Нужны примеры...
От: gandalfgrey  
Дата: 29.11.08 11:45
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>О чём и речь: пока у них есть возможность пркрываться бумажками и нет желания углубляться в существо, так всё и происходит.

Это уже чистой воды кадровая политика : нанимают таких, которые следуют этим заветам ( "не суйся — целее будешь" и т.д ).

ГВ>Именно, что формально.

По крайней мере, ЭТО они могут понять тогда как что-то другое им обьяснять просто бесполезно.

ГВ>До некоторой степени. Сам понимаешь, что уязвимость системы определяется самым уязвимым звеном. Если скрипт выполняет какую-то критически важную работу, и при этом не защищён от неуправляемых обновлений, то это называется "дыркой". Пусть он даже работает в трёхслойном сандбоксе.

Понятно, что именно до некоторой степени ! Но тут есть парадокс : когда я собирал статистику среди телемехаников, на первом месте стояла надежность системы — и это понятно. А вот при эксплуатации на передний план незаметным образом выползает гибкость, оттесняя надежность назад. Причем у тех же самых людей, надо заметить.
Так что приходится балансировать между тем и другим. Не создается ли тут перевес в одну сторону — вопрос насущный.
Re[20]: Нужны примеры...
От: gandalfgrey  
Дата: 29.11.08 11:51
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Let them crash?

Именно ! Процесс, который не может с чем-то справиться, помирает. Об этом узнает супервизор и принимает некие меры — например, перезапускает покойничка. Суть в том, что не надо использовать защитное программирование и даже наоборот, надо заставлять процесс подыхать при малейшем выходе за пределы его логики. Пример :


{ok,Bin}=file:read_file("settings")

Ежели файл не прочелся/ не найден или еще чего, процесс помрет из-за ошибки паттерн матчинга, потому как функция вернет {error, чего-то там}. Если все правильно, в Bin будет лежать содержимое файла.
Re[21]: Нужны примеры...
От: gandalfgrey  
Дата: 29.11.08 11:54
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не, ты не понял. Диспетчер получит по ушам первым, если что пойдёт не так, но это уже критический случай. Задача руководителей — найти такие способы организации работы, чтобы снизить вероятность такого события. Я именно об этом говорил.

Тут согласен

ГВ>Хех. Приёмо-сдачу устраивают не для словоблудства, а для передачи ответственности. Но это опять таки — по уму. По тому же уму, чтобы сократить количество приёмо-сдаточных мероприятий (и вообще — метаний), предварительно занимаются сбором и анализом требований, пожеланий и т.п. Но это "по уму".

Закачикам свойственно метаться...

ГВ>Ты не понял. Деструктивный код приводит к нарушению работы системы. Вышибанием в core dump или ошибкой округления значения температуры — не суть важно. Преднамеренность тоже не особо важна для оценки деструктивности.

Есть обратимые нарушения ( после которых система может самовосстановиться ) и есть необратимые. Разница, думаю, ясна
Re[21]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.11.08 12:00
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Let them crash?

G>Именно ! [...]

Ну, я так и думал: если на C++ мы получаем относительно редкие, но "большие" падения, то на языках типа Эрланга — мелкие, но много. Это не в упрёк Эрлангу, не подумай. Просто обычная семантика возобновления, которая в защищённых условиях может использоваться без особых трудностей.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: Сериализация и языки
От: gandalfgrey  
Дата: 29.11.08 12:02
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Я тебе про Фому, а ты мне про Ерёму. Технические сложности давай уж отдельно, организационные — отдельно. Я понимаю, что реальные условия обычно противоречивы и полны глупостей, но это не означает, что глупости перестают быть таковыми. В твоём случае я вижу организационную глупость, связанную с тем, что код вроде бы и нельзя обновлять, но в то же время можно. Можно называеть это корпоративным бюрократизмом, можно ещё как-то — не суть. Суть в том, что у ваших заказчиков эммм... несколько противоречивый подход к организации обновлений.

Дык ить, если бы у одного заказчика ! У всех так, как это ни печально


ГВ>>>Таким образом, народ жаждет, чтобы [...]

G>>А вот уже уже утрирование

ГВ>Вот и хорошо. Хотя в сущности этот абзац не противоречит предыдущему.

Не противоречит, но акценты расставлены несколько иначе

ГВ>Ничего революционного в передаче алгоритмов по проводам нет. Революционными были твои формулировки задач на передачу алгоритмов. Я зацепился за твоё высказывание о том, что программа-де может самонастраиваться на обработку новых форматов данных и т.п. На поверку выходит, что никакой неожиданной "самонастройки" на самом деле нет — есть всё то, о чём упомянули твои оппоненты: предварительная подготовка требований, предварительная подготовка системы к самонастройке в виде "закладок", заранее согласованный протокол и т.п.

Гм ! Все, что я хотел сказать — это то, что мой подход позволяет сократить эти процедуры, иногда очень сильно. Но ликвидировать их совсем — не получится. Хотя бы потому, что некий начальный протокол ДОЛЖЕН быть согласован — даже если потом он будет равиваться сам по щучьему велению
Ну, и должна быть спроектирована архитектура, которая позволит производить эти модификации / самомодификации без изменения ядра системы на максимально возможный срок.
Re[23]: Нужны примеры...
От: gandalfgrey  
Дата: 29.11.08 12:04
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Эх.

Я уже как-то привык...

ГВ>Э-э-э... Ты пытаешься возразить? Последовательность-то, вроде, не меняется: требование, потом формат, потом реализация.

Опечатался — сначала требование, потом реализация — а потом требования меняются под прямым углом. Дескать, мы имели в виду именно это
Re[22]: NB: Ещё один момент
От: gandalfgrey  
Дата: 29.11.08 12:07
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Загадочная это штука — корпоративный бюрократизм. И бумажки, вроде, есть, и зачем они — не ясно.

Сие таинство, однако

ГВ>Это может быть реализовано либо аппаратно, либо на недоступном для обновляемого ПО уровне. Но это гипотетически, я не знаю той аппаратуры, с которой вы работаете.

Концевая аппаратура — это всегда голая электромеханика, даже без электроники. Вот только доступ к ней происходит через несколько цепочек
Re[25]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.11.08 12:11
Оценка: +1
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>До некоторой степени. Сам понимаешь, что уязвимость системы определяется самым уязвимым звеном. Если скрипт выполняет какую-то критически важную работу, и при этом не защищён от неуправляемых обновлений, то это называется "дыркой". Пусть он даже работает в трёхслойном сандбоксе.

G>Понятно, что именно до некоторой степени ! Но тут есть парадокс : когда я собирал статистику среди телемехаников, на первом месте стояла надежность системы — и это понятно. А вот при эксплуатации на передний план незаметным образом выползает гибкость, оттесняя надежность назад. Причем у тех же самых людей, надо заметить.

Ну и чему тут удивляться? ИМХО, это как раз отражает некую "иерархию приоритетов": прежде всего — надёжность; далее, когда уже подразумевается, что с надёжностью всё в порядке — удобство. В рабочих условиях чаще всего вспоминают про удобство — это ежу понятно. Но удобное ненадёжному не предпочтут, скорее всего, поскольку плюсы от удобства не перекроют минусов от большей возни с ненадёжным устройством.

G>Так что приходится балансировать между тем и другим. Не создается ли тут перевес в одну сторону — вопрос насущный.


Тут вопрос даже не в перевесе, а в возможном неумышленном самообмане, который окажется миной замедленного действия.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: Нужны примеры...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.11.08 12:13
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

G>>Понятно, что именно до некоторой степени ! Но тут есть парадокс : когда я собирал статистику среди телемехаников, на первом месте стояла надежность системы — и это понятно. А вот при эксплуатации на передний план незаметным образом выползает гибкость, оттесняя надежность назад. Причем у тех же самых людей, надо заметить.


ГВ>Ну и чему тут удивляться? ИМХО, это как раз отражает некую "иерархию приоритетов": прежде всего — надёжность; далее, когда уже подразумевается, что с надёжностью всё в порядке — удобство. В рабочих условиях чаще всего вспоминают про удобство — это ежу понятно. Но удобное ненадёжному не предпочтут, скорее всего, поскольку плюсы от удобства не перекроют минусов от большей возни с ненадёжным устройством.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Нужны примеры...
От: gandalfgrey  
Дата: 29.11.08 12:19
Оценка: 1 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну, я так и думал: если на C++ мы получаем относительно редкие, но "большие" падения, то на языках типа Эрланга — мелкие, но много. Это не в упрёк Эрлангу, не подумай. Просто обычная семантика возобновления, которая в защищённых условиях может использоваться без особых трудностей.

Как говорит крутой парень Джо Армстронг — падения в Ерланге есть норма жизни. Главное, что мы всегда можем их обработать и отреагировать.
Re[27]: Нужны примеры...
От: gandalfgrey  
Дата: 29.11.08 12:24
Оценка:
Здравствуйте, eao197, Вы писали:

E>Кстати да! На моем веку было именно так -- "дайте нам больше гибкости, но чтобы надежность ни в коем случае не пострадала". Временами одновременно требуют повышения и того, и другого.

А иногда требуют гибкости за счет надежности / безопасности, просто не говоря об этом явно...
Re[28]: Нужны примеры...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.11.08 12:29
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

E>>Кстати да! На моем веку было именно так -- "дайте нам больше гибкости, но чтобы надежность ни в коем случае не пострадала". Временами одновременно требуют повышения и того, и другого.

G>А иногда требуют гибкости за счет надежности / безопасности, просто не говоря об этом явно...

Мне, наверное, повезло. Но требований снижения надежности я не припомню.

Хотя, может быть из-за того, что надежность C++ных программ /как здесь очень многие полагают/ и так уже ниже плинтуса?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Сериализация и языки
От: vdimas Россия  
Дата: 29.11.08 12:32
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

E>>ASN.1, Google Protocol Buffers, Boost.Serialization, s11n.net, даже мой собственный велосипед ObjESSty -- все это работает без встроенной поддержки со стороны языка.

G>Нууууууууу...это все не то. АСН.1 требует предварительного описания, к примеру

А как же без описания в задачах, где требуется сериализация? Если бы нам надо было гонять данные только лишь м/у абсолютно совместимыми (напр. по языку, железу и отображением структур в памяти) системами, то можно было бы прямо куски памяти гонять, без морок с какой-то сериализацией.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[4]: Сериализация и языки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.11.08 12:35
Оценка:
Здравствуйте, vdimas, Вы писали:

V>А как же без описания в задачах, где требуется сериализация? Если бы нам надо было гонять данные только лишь м/у абсолютно совместимыми (напр. по языку, железу и отображением структур в памяти) системами, то можно было бы прямо куски памяти гонять, без морок с какой-то сериализацией.


А так же, как в случае с XML (без DTD или XSD), JSON, YAML... Там формат практически самоописывающийся.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[26]: Нужны примеры...
От: gandalfgrey  
Дата: 29.11.08 12:44
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну и чему тут удивляться? ИМХО, это как раз отражает некую "иерархию приоритетов": прежде всего — надёжность; далее, когда уже подразумевается, что с надёжностью всё в порядке — удобство. В рабочих условиях чаще всего вспоминают про удобство — это ежу понятно. Но удобное ненадёжному не предпочтут, скорее всего, поскольку плюсы от удобства не перекроют минусов от большей возни с ненадёжным устройством.

Когда выбирают надежную, но дубовую систему или гибкую, но менее устойчивую — часто делают по факту выбор №2, на словах провозглашая приоритет выбора №1

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

Эхехехе...Есть такое понятие — цейтнот, которое совсем не способствует вдумчивому взвешиванию всех вариантов и последствий их использования. Но даже и без аврала — как сложить в один мешок несовместимые требования ? Вот и приходится выбирать меньшее зло, или то зло, что лучше пахнет, или хотя бы приятнее на вид 8))
Re[24]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.11.08 12:58
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Я тебе про Фому, а ты мне про Ерёму. Технические сложности давай уж отдельно, организационные — отдельно. Я понимаю, что реальные условия обычно противоречивы и полны глупостей, но это не означает, что глупости перестают быть таковыми. В твоём случае я вижу организационную глупость, связанную с тем, что код вроде бы и нельзя обновлять, но в то же время можно. Можно называеть это корпоративным бюрократизмом, можно ещё как-то — не суть. Суть в том, что у ваших заказчиков эммм... несколько противоречивый подход к организации обновлений.

G>Дык ить, если бы у одного заказчика ! У всех так, как это ни печально

Дык ить — не сомневаюсь. Меня в таких коллизиях напрягает то, что дядьки в дорогих костюмах играют в корпоративные бумажки, а в среде технических специалистов уживаются некие "мифы", типа того, который ты озвучил в первых сообщениях. На поверку, разумеется, вышло, что чуда никакого нет. Всё осталось на своих местах, как всегда.

ГВ>>Ничего революционного в передаче алгоритмов по проводам нет. Революционными были твои формулировки задач на передачу алгоритмов. Я зацепился за твоё высказывание о том, что программа-де может самонастраиваться на обработку новых форматов данных и т.п. На поверку выходит, что никакой неожиданной "самонастройки" на самом деле нет — есть всё то, о чём упомянули твои оппоненты: предварительная подготовка требований, предварительная подготовка системы к самонастройке в виде "закладок", заранее согласованный протокол и т.п.

G>Гм ! Все, что я хотел сказать — это то, что мой подход позволяет сократить эти процедуры, иногда очень сильно. Но ликвидировать их совсем — не получится. Хотя бы потому, что некий начальный протокол ДОЛЖЕН быть согласован — даже если потом он будет равиваться сам по щучьему велению

С одной строны, сейчас ты сформулировал примерно то же самое, о чём тебе говорили с самого начала. С другой — совсем ликвидировать приёмо-сдаточные процедуры нельзя по организационным соображениям. С третьей стороны — твой подход может упростить не столько сами процедуры, сколько развёртывание обновлений после приёмки. Это снова — "по уму". Честно говоря, "минусовать" руководство ваших заказчиков я тут уже запарился.

G>Ну, и должна быть спроектирована архитектура, которая позволит производить эти модификации / самомодификации без изменения ядра системы на максимально возможный срок.


Да-да-да. Именно так, сначала — общие соглашения о том что куда можно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.11.08 13:03
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Ну и чему тут удивляться? ИМХО, это как раз отражает некую "иерархию приоритетов" [...]

G>Когда выбирают надежную, но дубовую систему или гибкую, но менее устойчивую — часто делают по факту выбор №2, на словах провозглашая приоритет выбора №1

Ну, если всем всё по х.., то медицина бессильна.

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

G>Эхехехе...Есть такое понятие — цейтнот, которое совсем не способствует вдумчивому взвешиванию всех вариантов и последствий их использования. Но даже и без аврала — как сложить в один мешок несовместимые требования ? Вот и приходится выбирать меньшее зло, или то зло, что лучше пахнет, или хотя бы приятнее на вид 8))

Ну что тут скажешь... Как всегда, всё сходится на руководстве: не сам же по себе этот самый цейтнот возникает.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.11.08 13:05
Оценка:
Здравствуйте, eao197, Вы писали:

E>Кстати да! На моем веку было именно так -- "дайте нам больше гибкости, но чтобы надежность ни в коем случае не пострадала". Временами одновременно требуют повышения и того, и другого.


Это как раз нормально: кому нужно второстепенное качество без первоочередного?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: Нужны примеры...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.11.08 13:07
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Это как раз нормально: кому нужно второстепенное качество без первоочередного?


Ну да, это нормально. Вот только gandalfgrey в других условиях оказался. Или ему так сейчас кажется.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.11.08 13:07
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

E>>Кстати да! На моем веку было именно так -- "дайте нам больше гибкости, но чтобы надежность ни в коем случае не пострадала". Временами одновременно требуют повышения и того, и другого.

G>А иногда требуют гибкости за счет надежности / безопасности, просто не говоря об этом явно...

Мда... А потом ещё что-то говорят про программистов, цивилизацию и дятлов...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[29]: Нужны примеры...
От: gandalfgrey  
Дата: 29.11.08 14:51
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Мда... А потом ещё что-то говорят про программистов, цивилизацию и дятлов...

Это карма ! Видимо, мы слишком грешили в предыдущей жизни и за это несем сейчас всю тяжесть ответственности. Pundis Mundi, так сказать 8))
Re[28]: Нужны примеры...
От: gandalfgrey  
Дата: 29.11.08 14:55
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну, если всем всё по х.., то медицина бессильна.

Ампутация части требований иногда спасает, но это долгий и болезненный процесс

ГВ>Ну что тут скажешь... Как всегда, всё сходится на руководстве: не сам же по себе этот самый цейтнот возникает.

Дело в том, что от технических специалистов требуется знание и понимание того, что они делают. Это требуют даже от дорожных рабочих. А вот разнокалиберное начальство находится совершенно в другом положении — им просто не надо знать и понимать хоть что-то, да они этого и не хотят
Re[29]: Нужны примеры...
От: gandalfgrey  
Дата: 30.11.08 02:19
Оценка:
Здравствуйте, eao197, Вы писали:

ГВ>>Это как раз нормально: кому нужно второстепенное качество без первоочередного?

E>Ну да, это нормально. Вот только gandalfgrey в других условиях оказался. Или ему так сейчас кажется.
А чего вы, собственно, удивляетесь ? Или никогда не видели, как люди выбирают какой-либо продукт за рюшечки, не сильно интересуясь качеством и функциональностью ? Ничего странного тут нет
Re[28]: Нужны примеры...
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.12.08 05:52
Оценка: 2 (1) +1
Здравствуйте, eao197, Вы писали:

E>Обновлять алгоритмы обработки удаленно в C++ хоть и проблематично, но все-таки возможно. Например, можно готовые DLL-ки со специальной точкой входа пересылать. Удаленная сторона их сохраняет, подгружает и интегрирует в свой основной процесс. Хотя лучше это все-таки делать другими средствами, с возможностью быстрого отката к предыдущим версиям.

Ну, DLL может оказаться оверкиллом. Хотя, если ограничиться определенным подмножеством задач (для которого, к примеру, не нужна таблица импорта), то это может и сработать.
Альтернативой могла бы быть передача некоего байт-кода, к примеру LLVM, который после JIT заработает на сервере.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Сериализация и языки
От: vdimas Россия  
Дата: 01.12.08 09:01
Оценка: +2
Здравствуйте, eao197, Вы писали:

V>>А как же без описания в задачах, где требуется сериализация? Если бы нам надо было гонять данные только лишь м/у абсолютно совместимыми (напр. по языку, железу и отображением структур в памяти) системами, то можно было бы прямо куски памяти гонять, без морок с какой-то сериализацией.


E>А так же, как в случае с XML (без DTD или XSD), JSON, YAML... Там формат практически самоописывающийся.


Не самоописывающийся, а структурированный. В похожем смысле и ASN.1 BER самоописывающийся.
В любом случае, приёмная сторона должна знать, что с этой структурой делать. И если мы зачастую DTD/XSD в виде отдельных док-тов не делаем, это не значит, что их аналогов нет у нас в голове в момент написания сериализатора/парсера некоего своего XML, иначе просто нихрена работать не будет.
... << RSDN@Home 1.2.0 alpha rev. 786>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.