Здравствуйте, Ikemefula, Вы писали:
S>>Выиграли те, кто инвестировал в фундаментальные вещи — например, в разбирательство с тем, как устроен протокол HTTP.
I>Правильно. А если сегодня ты учишь одну технологию, завтра — другую, не совсем ясно, где взять время на изучение HTTP.
А, вот ещё подумал: как это высказывание соотносится с вашим
Мне исходники не нужны, мне нужны технологии, как раз те, что могла выдать микрософт но не выдала.
?
Ровно то же и получается: те, кто не хочет разбираться с XmlHttpRequest, а вместо этого хочет "учить технологию", обречены через пару лет учить другую технологию. А опыт тех, кто разобрался с XmlHttpRequest, будет востребован и через пять лет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ровно то же и получается: те, кто не хочет разбираться с XmlHttpRequest, а вместо этого хочет "учить технологию", обречены через пару лет учить другую технологию. А опыт тех, кто разобрался с XmlHttpRequest, будет востребован и через пять лет.
Похоже, эту фичу не оценил не только микрософт, но почти поголовно все разработчики и конторы
Здравствуйте, Sinclair, Вы писали:
S>Ок, ну вот теперь мы определились. А то вы обмолвились, что МС чего-то мог, но не сделал, что меня и удивило до крайности. S>А так-то я согласен: мог смочь, если бы знал чего хотеть, но хотел не того, в итоге того и не смог Пытается теперь смочь. С некоторым опозданием.
так и есть, "мог смочь, если бы..." С Башаром Асадом тоже самое -я "мог смочь, если бы..."
S>А теперь мне было бы интересно посмотреть на пример реальной задачи, которая типа влёт решается на co-SQL и никак не решается на SQL (ну, или точнее — на современной RDBMS, которые по факту все постреляционные)
См верхнюю часть рисунка. Здесь два слоя, ам где линки синие и где красные. Синий слой один, Красных слоев может быть больше одного. Синий слой роутится через несколько красных. Красный слой роутится через несколько нижележащих красных. Один линк роутится только на один слой. По одному линку может проходить трафик нескольких других линков разных слоев.
Объем сети где то от 100К объекто, слоев около 10-15. Синих линков около 10-15К. Узлов 1К-10к тыс. Красных линков 60К.
1. Нужно по клику мышом на конкретный элемент(или группу элементов, типа узел, линк и тд) показать где идет его трафик или, наоброт, чей трафик проходит через него.
Пути, их два типа — основной и резервный. Каждый путь состоит из конкретных элементов, у каждого элемента на нижележащем слое всегда будет два типа путей, основной и резервный и тд и тд.
Основной красится одним цветом, резервный — другим.
Основной резервного будет краситься в резервный цвет, а резервный основного будет краситься в основной и тд. Часть элементов может принадлежать как основному пути, так и резервному, скажем, через два три слоя, такие красятся зеброй.
2 Самый нижний слой — физический, это волокно. Обновить длину логических линков в соответствии с роутингом для основного пути.
Здравствуйте, Ikemefula, Вы писали:
I>Похоже, эту фичу не оценил не только микрософт, но почти поголовно все разработчики и конторы
В каком смысле?
Весь AJAX построен на ней.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Похоже, эту фичу не оценил не только микрософт, но почти поголовно все разработчики и конторы S>В каком смысле? S>Весь AJAX построен на ней.
Здравствуйте, Ikemefula, Вы писали: I>так и есть, "мог смочь, если бы..." С Башаром Асадом тоже самое -я "мог смочь, если бы..."
Давайте уже про Асада прекратим. Подбирать аналогии — искусство, в данном случае вы его не проявили.
I>Мне сложновато накидать простой пример. I>http://www.lit.lnt.de/Topics/Optic/OptHomepage_Img/OpticalTransportNet.jpg
I>См верхнюю часть рисунка. Здесь два слоя, ам где линки синие и где красные. Синий слой один, Красных слоев может быть больше одного. Синий слой роутится через несколько красных. Красный слой роутится через несколько нижележащих красных. Один линк роутится только на один слой.
Вот это непонятно — что значит "один линк роутится только на один слой".
I> По одному линку может проходить трафик нескольких других линков разных слоев.
По каким правилам? I>Объем сети где то от 100К объекто, слоев около 10-15. Синих линков около 10-15К. Узлов 1К-10к тыс. Красных линков 60К.
I>1. Нужно по клику мышом на конкретный элемент(или группу элементов, типа узел, линк и тд) показать где идет его трафик или, наоброт, чей трафик проходит через него.
И это всё на одной картинке? 100K объектов, с 60K линков?
Слабо себе представляю. Впрочем, неважно — вопросы отсечения можно пока оставить. I>Пути, их два типа — основной и резервный. Каждый путь состоит из конкретных элементов, у каждого элемента на нижележащем слое всегда будет два типа путей, основной и резервный и тд и тд. I>Основной красится одним цветом, резервный — другим. I>Основной резервного будет краситься в резервный цвет, а резервный основного будет краситься в основной и тд. Часть элементов может принадлежать как основному пути, так и резервному, скажем, через два три слоя, такие красятся зеброй.
I>2 Самый нижний слой — физический, это волокно. Обновить длину логических линков в соответствии с роутингом для основного пути.
I>Хочется получать данные за "время клика".
Пока что возникает ощущение, что всё известно статически. Простые связи типа "синий линк A роутится через красные линки A1, A2, A3" достаются влёт. Связи типа "из узла Х достижимы узлы Y, Z, W" вычисляются заранее путём построения транзитивного замыкания (быть может, ограниченного).
Ну, и вообще business case для RDBMS здесь не вполне понятен. Для read-only операций DBMS вообще не нужны. DBMS нужны для совместной работы (то есть чтений и модификаций) многих пользователей (или агентов) над структурированными данными.
А в вашей задаче вообще про изменения ни слова нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Я не понимаю ваших высказываний. Вы явно пользуетесь терминами в каком-то отличном от других смысле. Вместо "технология" вы говорите "функция", вместо "инструмент" вы говорите "технология", вместо "евангелизировать" говорите "выдать", вместо "популярность" говорите "появление". Странно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Ajax как технология появился примерно в 2005м S>AJAX как технология появился в OWA.
Одного применения слишком мало что бы метод считать технологией. Эдак в каждом приложении окажется технологий столько, сколько уникальных строчек кода.
S>В 2005 эта технология получила популярность — вышла пачка книг.
Метод становится технологией когда проходит некоторые процедуры, примерно как верификация и фальсификация в науке. разница только в том, что нет однозначного простого критерия типа "если звезда которая должна быть видна ровно на границе окружности солнца имеет видимое смещение ~a то законы ньютоновские, а если ~б то законы релятивистские". Соответсвенно одиночного применения недостаточно, что бы считать метод технологией.
S>Я не понимаю ваших высказываний. Вы явно пользуетесь терминами в каком-то отличном от других смысле. Вместо "технология" вы говорите "функция", вместо "инструмент" вы говорите "технология", вместо "евангелизировать" говорите "выдать", вместо "популярность" говорите "появление". Странно.
Ты лучше сам подумай чего ты говоришь. Все функции у тебя можно назвать технологиями Ну от в чем разница между alert и XmlHttpRequest ? И то и другое можно считать технологией Сюда же можно добавить Trim Slice ToString и тд и тд и тд.
Здравствуйте, Ikemefula, Вы писали:
S>>Я не понимаю ваших высказываний. Вы явно пользуетесь терминами в каком-то отличном от других смысле. Вместо "технология" вы говорите "функция", вместо "инструмент" вы говорите "технология", вместо "евангелизировать" говорите "выдать", вместо "популярность" говорите "появление". Странно. I>Ты лучше сам подумай чего ты говоришь. Все функции у тебя можно назвать технологиями Ну от в чем разница между alert и XmlHttpRequest ? И то и другое можно считать технологией Сюда же можно добавить Trim Slice ToString и тд и тд и тд.
AJAX это не только XmlHttpRequest. AJAX — это такая технология/подход, когда для взаимодейтсвия с сервером не нужно перегружать страницы web-агента, а динамически в фоне посылать запросы и производить на основании данных полученных с сервера произвольные действия, в т.ч. динамически изменять страницы/интерфейс. А XmlHttpRequest — интерфейс для фонового взаимодействия с сервером; т.е. одна из фундаментальных составляющих AJAX.
Ты же нафантазировал себе, что AJAX = XmlHttpRequest и с умным видом развёл тут пустую демагогию основываясь на неверном предположении.
Здравствуйте, nullxdth, Вы писали:
N>Ты же нафантазировал себе, что AJAX = XmlHttpRequest и с умным видом развёл тут пустую демагогию основываясь на неверном предположении.
Не я, а кое кто другой тут утверждает что AJAX = XmlHttpRequest и это де есть технология.
В любом случае единичное применение Аджакса не дает оснований считать его технологией. Технология это некоторые распространяемые, проверяемые, фальсифицируемые знания о некотором методе. Если достаточно единичного применения, то эдак любой набор функций и даже одна функция станет технологией.
Или такой пример — чай как технология появился не тогда, когда ктото стал добавлять в кипяток листья чайного дерева, а много позже, когда некто другой написал целую книгу про это.
Или другой пример, технология "рычаг" появилась не тогда, когда ктото с помощью палки сдвинул с места большой предмет, а намного позже, когда эти знания стали распространяемыми, проверяемыми, фальсифицируемыми .
Здравствуйте, Ikemefula, Вы писали: I>Одного применения слишком мало что бы метод считать технологией. Эдак в каждом приложении окажется технологий столько, сколько уникальных строчек кода.
Ваше понимание технологии противоречит общепринятому. Скажем, вот если некая страна получила технологию очистки плутония, то технология существует. Несмотря на то, что другие страны могут этой технологии не иметь.
I>Метод становится технологией когда проходит некоторые процедуры, примерно как верификация и фальсификация в науке. разница только в том, что нет однозначного простого критерия типа "если звезда которая должна быть видна ровно на границе окружности солнца имеет видимое смещение ~a то законы ньютоновские, а если ~б то законы релятивистские". Соответсвенно одиночного применения недостаточно, что бы считать метод технологией.
А по мне так вполне достаточно. Я не вижу принципиальной разницы между наличием на рынке только OWA и OWA+Gmail.
I>Ты лучше сам подумай чего ты говоришь. Все функции у тебя можно назвать технологиями Ну от в чем разница между alert и XmlHttpRequest ? И то и другое можно считать технологией Сюда же можно добавить Trim Slice ToString и тд и тд и тд.
Нет. Технологией является AJAX. Его основа — это DHTML (то есть набор методов по динамической модификации DOM) и XmlHttpRequest (то есть способ получать от сервера данные). Без CSS можно обойтись, без XML можно обойтись.
Технологией является способ совместного применения этих функций для получения определённой пользовательской функциональности.
Поэтому я и говорю, что с момента первой реализации XmlHttpRequest и построения на его основе примера приложения, технологию можно считать состоявшейся. Никаких дополнительных "некоторых процедур", сформулировать которые вы не можете, для этого не надо. Процедура ровно одна — построение приложения. Без этого технология остаётся умозрительной.
Если вы ухитритесь разработать метод решения некоторого класса задач на основе функции alert(), то его тоже можно будет считать технологией. Даже если никто больше не будет владеть этой технологией. Но я спокоен за функцию alert(), равно как и trim(), slice(), toString(). Кстати, на основе последней работает jQuery. Если бы не toString(), то целый фреймворк бы не удалось построить
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Одного применения слишком мало что бы метод считать технологией. Эдак в каждом приложении окажется технологий столько, сколько уникальных строчек кода. S>Ваше понимание технологии противоречит общепринятому. Скажем, вот если некая страна получила технологию очистки плутония, то технология существует. Несмотря на то, что другие страны могут этой технологии не иметь.
Получить такую технологию вовсе не значит очистить плутоний один раз
I>>Метод становится технологией когда проходит некоторые процедуры, примерно как верификация и фальсификация в науке. разница только в том, что нет однозначного простого критерия типа "если звезда которая должна быть видна ровно на границе окружности солнца имеет видимое смещение ~a то законы ньютоновские, а если ~б то законы релятивистские". Соответсвенно одиночного применения недостаточно, что бы считать метод технологией. S>А по мне так вполне достаточно. Я не вижу принципиальной разницы между наличием на рынке только OWA и OWA+Gmail.
OWA необходимо, Gmail — уже достаточно
I>>Ты лучше сам подумай чего ты говоришь. Все функции у тебя можно назвать технологиями Ну от в чем разница между alert и XmlHttpRequest ? И то и другое можно считать технологией Сюда же можно добавить Trim Slice ToString и тд и тд и тд. S>Нет. Технологией является AJAX. Его основа — это DHTML (то есть набор методов по динамической модификации DOM) и XmlHttpRequest (то есть способ получать от сервера данные). Без CSS можно обойтись, без XML можно обойтись.
Я согласен с тем что Аджакс это технология. Я всего то утверждаю, что она появилась в 2005м году.
S>Если вы ухитритесь разработать метод решения некоторого класса задач на основе функции alert(), то его тоже можно будет считать технологией. Даже если никто больше не будет владеть этой технологией.
Здравствуйте, Sinclair, Вы писали:
I>>См верхнюю часть рисунка. Здесь два слоя, ам где линки синие и где красные. Синий слой один, Красных слоев может быть больше одного. Синий слой роутится через несколько красных. Красный слой роутится через несколько нижележащих красных. Один линк роутится только на один слой. S>Вот это непонятно — что значит "один линк роутится только на один слой".
Слои собтсвенно и создают иерархию, это статически задается. Есть слои A,B,C,D. Верхний слой A может роутиться на B, C, D хоть по одному, хоть на все сразу. Но конкретный линк из A будет роутиться только на один из слоев.
I>> По одному линку может проходить трафик нескольких других линков разных слоев. S>По каким правилам?
Не ясно, зачем тебе это надо
Условно так — у линка есть капасити, сигналы верхнего уровня тоже имеют капасити, сумма капасити сигналов сверху не должна превышать капасити линка. Рельно у линка есть N каналов, у каждого канала свой капасити, один сигнал сверху занимает ровно один канал если позволяет капасити. Решение задачи распределения каналов очень похоже на решение судоку или раскраску графа.
I>>Объем сети где то от 100К объекто, слоев около 10-15. Синих линков около 10-15К. Узлов 1К-10к тыс. Красных линков 60К. I>>1. Нужно по клику мышом на конкретный элемент(или группу элементов, типа узел, линк и тд) показать где идет его трафик или, наоброт, чей трафик проходит через него. S>И это всё на одной картинке? 100K объектов, с 60K линков?
Как это рисуется, не важно, если есть желание получить кашу можно и все на один скрин кинуть От тебя требуется выдать такую вещь LinkId — Color, NodeId — Color. Color это [основной, резервный, зебра].
I>>2 Самый нижний слой — физический, это волокно. Обновить длину логических линков в соответствии с роутингом для основного пути.
I>>Хочется получать данные за "время клика". S>Пока что возникает ощущение, что всё известно статически. Простые связи типа "синий линк A роутится через красные линки A1, A2, A3" достаются влёт. Связи типа "из узла Х достижимы узлы Y, Z, W" вычисляются заранее путём построения транзитивного замыкания (быть может, ограниченного).
Именно так. Это специфика оптической сети, они работают сильно отлично от Ethernet или ATM.
S>Ну, и вообще business case для RDBMS здесь не вполне понятен. Для read-only операций DBMS вообще не нужны. DBMS нужны для совместной работы (то есть чтений и модификаций) многих пользователей (или агентов) над структурированными данными. S>А в вашей задаче вообще про изменения ни слова нет.
Вторая задача как раз про изменения. Есть клиент-серверное приложение, где сеть редактирует целая куча людей. Там кастомер хочет видеть ровно те же самые функции — визуализацию в частности. Делается примерно так — создается некоторый срез, отсылается на клиент, от него изменения записываются в общую базу. Вот эта вещь очень сильно бесит кастомера, т.к. "глянуть" может занять несколько минут. Отсюда визуализация в клиент-серверном еще в каменном веке, а десктоп сильно проигрывает по объему хранимых данных.
Здравствуйте, Ikemefula, Вы писали:
I>Слои собтсвенно и создают иерархию, это статически задается. Есть слои A,B,C,D. Верхний слой A может роутиться на B, C, D хоть по одному, хоть на все сразу. Но конкретный линк из A будет роутиться только на один из слоев.
Ок. Давайте вводить хоть какую-то формализацию, потому что по картинке и словам нихрена непонятно.
Давайте будем обозначать объекты-узлы номерами и буквами — буква означает слой. То есть, например, A1, А2, А3, B1, и так далее.
Судя по картинке, между некоторыми узлами из разных слоёв есть соответствие, но не для всех. То есть мы имеем B1, B2, B3, но только A1 и A3. A2 не существует.
Линк у нас будет обозначаться как просто пара узлов. Т.к. линк бывает только в пределах одного слоя, будем его обозначать буквой и, в скобках, номера слинкованных узлов: A(1, 3), B(1, 2).
Теперь, я так понимаю, "роутиться" — это функция A(1, 3) -> {B(1, 2), B(2, 3)}?
Причём никакой задачи поиска роута в реальном времени не стоит, это просто статическая информация?
I>Не ясно, зачем тебе это надо
Надо же понять, в чём собственно задача.
I>Условно так — у линка есть капасити, сигналы верхнего уровня тоже имеют капасити, сумма капасити сигналов сверху не должна превышать капасити линка. Рельно у линка есть N каналов, у каждого канала свой капасити, один сигнал сверху занимает ровно один канал если позволяет капасити. Решение задачи распределения каналов очень похоже на решение судоку или раскраску графа.
Это та задача, которую мы решаем, или это какая-то другая задача?
I>Как это рисуется, не важно, если есть желание получить кашу можно и все на один скрин кинуть От тебя требуется выдать такую вещь LinkId — Color, NodeId — Color. Color это [основной, резервный, зебра].
Непонятно, в чём сложность.
I>>>Хочется получать данные за "время клика". S>>Пока что возникает ощущение, что всё известно статически. Простые связи типа "синий линк A роутится через красные линки A1, A2, A3" достаются влёт. Связи типа "из узла Х достижимы узлы Y, Z, W" вычисляются заранее путём построения транзитивного замыкания (быть может, ограниченного).
I>Именно так.
Ок. Давайте прикидывать. Характерная длина "красного" роута для одного синего линка, судя по статистике, от 4х до 6 линков.
Пусть будет 5. То есть для каждого из 15к синих линков мы имеем набор из 5 интов, обозначающих номера узлов в роуте, +номер слоя. И всё это — дважды, для основного и резервного роутов. Итого — 10 интов, 40 байт. Плюс сам линк — это ещё два инта. Итого, 48 байт. Умножаем на 75k, получаем 3600000 байт. Всего, в целом.
Можно легко держать это всё в памяти клиента, и выдавать ответы на запросы типа "дай мне основной и резервный роут для линка w(x, y)" за микросекунды.
Что я понял неправильно?
I>Вторая задача как раз про изменения. Есть клиент-серверное приложение, где сеть редактирует целая куча людей. Там кастомер хочет видеть ровно те же самые функции — визуализацию в частности. Делается примерно так — создается некоторый срез, отсылается на клиент, от него изменения записываются в общую базу. Вот эта вещь очень сильно бесит кастомера, т.к. "глянуть" может занять несколько минут. Отсюда визуализация в клиент-серверном еще в каменном веке, а десктоп сильно проигрывает по объему хранимых данных.
Ничего не понял. Попробуйте объяснить поточнее. Что такое "редактирует", что такое "срез", какие изменения, что бесит. Что в каменном, и кому что проигрывает клиент.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Слои собтсвенно и создают иерархию, это статически задается. Есть слои A,B,C,D. Верхний слой A может роутиться на B, C, D хоть по одному, хоть на все сразу. Но конкретный линк из A будет роутиться только на один из слоев. S>Ок. Давайте вводить хоть какую-то формализацию, потому что по картинке и словам нихрена непонятно. S>Давайте будем обозначать объекты-узлы номерами и буквами — буква означает слой. То есть, например, A1, А2, А3, B1, и так далее. S>Судя по картинке, между некоторыми узлами из разных слоёв есть соответствие, но не для всех. То есть мы имеем B1, B2, B3, но только A1 и A3. A2 не существует.
Есть конечно. Узлы привязаны к географическим точкам. То есть, скажем, шкаф с оборудованием подключен к слоям A, B и D, это значит, что здесь три узла будет.
Скажем если ты гоняешь трафик на верхнем уровне между Москвой и Берлином, то на самом верхнем уровне всего два терминальных узла которые, на самом нижнем может быть пару тысяч и более транзитных узлов.
S>Линк у нас будет обозначаться как просто пара узлов. Т.к. линк бывает только в пределах одного слоя, будем его обозначать буквой и, в скобках, номера слинкованных узлов: A(1, 3), B(1, 2). S>Теперь, я так понимаю, "роутиться" — это функция A(1, 3) -> {B(1, 2), B(2, 3)}?
Еще тип пути — основной или резервный. Линков в пути может быть сколько угодно и даже могут цикл образовывать, обычно это простой цикл.
S>Причём никакой задачи поиска роута в реальном времени не стоит, это просто статическая информация?
Именно так. Это софт для проектирования, а не для симуляции.
I>>Условно так — у линка есть капасити, сигналы верхнего уровня тоже имеют капасити, сумма капасити сигналов сверху не должна превышать капасити линка. Рельно у линка есть N каналов, у каждого канала свой капасити, один сигнал сверху занимает ровно один канал если позволяет капасити. Решение задачи распределения каналов очень похоже на решение судоку или раскраску графа. S>Это та задача, которую мы решаем, или это какая-то другая задача?
Это я тебе объяснил, как сигналы верхнего уровня укладываются в нижележащие линки.
I>>Как это рисуется, не важно, если есть желание получить кашу можно и все на один скрин кинуть От тебя требуется выдать такую вещь LinkId — Color, NodeId — Color. Color это [основной, резервный, зебра]. S>Непонятно, в чём сложность.
У меня — никакой
I>>Именно так. S>Ок. Давайте прикидывать. Характерная длина "красного" роута для одного синего линка, судя по статистике, от 4х до 6 линков.
По картинке не видно, но длина роута может быть какой угодно. Реально для утилизации оборудования и всяких схем резервирования обычно алгоритмы роутинга стараются дававать длинные пути.
S>Пусть будет 5. То есть для каждого из 15к синих линков мы имеем набор из 5 интов, обозначающих номера узлов в роуте, +номер слоя.
Путь это линки, а не узлы. Между двумя узлами может быть сколько угодно линков одного типа и тд. Ну представь, никто не будет между двумя городами прокладывать оптический кабель в котором ровно один файбер, т.е. тонюсенький такой волосок Собственно логических линков тоже может быть больше одного.
>И всё это — дважды, для основного и резервного роутов. Итого — 10 интов, 40 байт. Плюс сам линк — это ещё два инта. Итого, 48 байт. Умножаем на 75k, получаем 3600000 байт. Всего, в целом. S>Можно легко держать это всё в памяти клиента, и выдавать ответы на запросы типа "дай мне основной и резервный роут для линка w(x, y)" за микросекунды. S>Что я понял неправильно?
Для одной конкретной задачи примерно так и будет, с поправкой на особенности роута, что я указал. Получить основной и резервный это частный случай. У каждого линка из любого пути будут в свою очередь так же основные и резервные пути. То есть, каждый слой роутится на нижележащие, и нужно скажем кликнув на линке верхнего уровня, получить полную картину на самом нижнем уровне, то есть, раскрутить весь роутинг по слоям.
Скажем, бывает такая ситуация — на верху всего один линк, а внизу — сотни и даже тысячи.
I>>Вторая задача как раз про изменения. Есть клиент-серверное приложение, где сеть редактирует целая куча людей. Там кастомер хочет видеть ровно те же самые функции — визуализацию в частности. Делается примерно так — создается некоторый срез, отсылается на клиент, от него изменения записываются в общую базу. Вот эта вещь очень сильно бесит кастомера, т.к. "глянуть" может занять несколько минут. Отсюда визуализация в клиент-серверном еще в каменном веке, а десктоп сильно проигрывает по объему хранимых данных.
S>Ничего не понял. Попробуйте объяснить поточнее. Что такое "редактирует", что такое "срез", какие изменения, что бесит. Что в каменном, и кому что проигрывает клиент.
Кастомер хочет "потрогать" роутинг. Это для разных целей используется. Ну вот самый простой случай — хочешь сравнить два разных роутинга. Кликнул мышом в линк и посмотрел, где идет его трафик или выделил пару узлов и смотрит, какую часть сети затронет сбой узла. Т.е. ответ надо получать очень быстро, не в реальном режиме времени, но желательно успевать за кликами оператора. "Редактирует" — это значит есть N людей, которые вносят изменения в проект сети, меняют чего то, удаляют чего то, ктото роутинг создает, ктото отдельные свойсвта меняет. Срез — возможно не так выразился, это просто часть сети, выборка по определенному условию, обычно географическому , например Канада. Сервер делает выборку, отдаёт на клиент, клиент чего то смотрит, меняет и отдает обратно серверу.
Подтянуть с сервера целую кучу данных крайне сложно, а после этого нужно еще визуализировать сеть и тд. Поэтому использовать запрошеную фичу крайне сложно. А вот в десктопном, имеется ввиду стандалон, наоброт, очень легко, т.к. не надо никуда ходить за данными, все доступно практически сразу.
I>Есть конечно. Узлы привязаны к географическим точкам. То есть, скажем, шкаф с оборудованием подключен к слоям A, B и D, это значит, что здесь три узла будет. I>Скажем если ты гоняешь трафик на верхнем уровне между Москвой и Берлином, то на самом верхнем уровне всего два терминальных узла которые, на самом нижнем может быть пару тысяч и более транзитных узлов.
Не вполне понятно, что на верхнем уровне. Прямой линк москва-берлин, или роут типа Москва-Калининград-Хельсинки-Берлин?
I>Еще тип пути — основной или резервный. Линков в пути может быть сколько угодно и даже могут цикл образовывать, обычно это простой цикл.
Этот момент непонятен. Что значит "цикл", и как это работает?
I>Именно так. Это софт для проектирования, а не для симуляции.
Угу.
I>У меня — никакой
Ок. I>>>Именно так. S>>Ок. Давайте прикидывать. Характерная длина "красного" роута для одного синего линка, судя по статистике, от 4х до 6 линков.
I>По картинке не видно, но длина роута может быть какой угодно.
I>Реально для утилизации оборудования и всяких схем резервирования обычно алгоритмы роутинга стараются дававать длинные пути.
Какова средняя длина пути?
I>Путь это линки, а не узлы. Между двумя узлами может быть сколько угодно линков одного типа и тд. Ну представь, никто не будет между двумя городами прокладывать оптический кабель в котором ровно один файбер, т.е. тонюсенький такой волосок Собственно логических линков тоже может быть больше одного.
Ок, принципиальной разницы это нам не меняет. Если линк идентифицируется не только парой соединённых узлов, то мы даём ему синтетический ключ linkId, и это по-прежнему один инт.
I>Для одной конкретной задачи примерно так и будет, с поправкой на особенности роута, что я указал. Получить основной и резервный это частный случай. У каждого линка из любого пути будут в свою очередь так же основные и резервные пути. То есть, каждый слой роутится на нижележащие, и нужно скажем кликнув на линке верхнего уровня, получить полную картину на самом нижнем уровне, то есть, раскрутить весь роутинг по слоям.
Ок, мы говорим о транзитивном замыкании. Которое вычисляется по данным, полный объём которых ложится в L1 cache процессора современного лэптопа. Всё ещё не понимаю, при чём тут RDBMS.
I>Скажем, бывает такая ситуация — на верху всего один линк, а внизу — сотни и даже тысячи.
Охтыж, "даже тысячи".
I>>>Вторая задача как раз про изменения. Есть клиент-серверное приложение, где сеть редактирует целая куча людей. Там кастомер хочет видеть ровно те же самые функции — визуализацию в частности. Делается примерно так — создается некоторый срез, отсылается на клиент, от него изменения записываются в общую базу. Вот эта вещь очень сильно бесит кастомера, т.к. "глянуть" может занять несколько минут. Отсюда визуализация в клиент-серверном еще в каменном веке, а десктоп сильно проигрывает по объему хранимых данных.
S>>Ничего не понял. Попробуйте объяснить поточнее. Что такое "редактирует", что такое "срез", какие изменения, что бесит. Что в каменном, и кому что проигрывает клиент.
I>Подтянуть с сервера целую кучу данных крайне сложно, а после этого нужно еще визуализировать сеть и тд.
Не понимаю проблемы подтянуть с сервера вашу "кучу данных". Полный объём — считанные мегабайты. Дельты, значит, будут исчисляться килобайтами. Здесь всё сводится к разработке структуры, удобной для двух целей:
1. Скорость визуализации — это основное.
2. Локальность изменений — это чтобы дельты были понятными (а не как в Rational Rose, где одно изменение в связях компонентов приводило к тысячам диффов в файле).
На основе этого реализуется кэширование — и вперёд, на танки.
Технологию персистенса на серверной стороне нужно выбирать уже после того, как станет понятен протокол между клиентом и сервером. Вполне может подойти и RDBMS, но я этого понять не могу, пока нет полной постановки задачи.
На первый взгляд вполне хватает тупой таблицы
Links(
id int primary key,
originationNode int --foreign key references Nodes(id),
destinationNode int --foreign key references Nodes(id),
forwardReferences varbinary(max),
backReferences varbinary(max)
)
В forwardReferences лежат ссылки на основной и резервный роуты (собственно, список пар {LinkId, Type}), в backReferences — наоборот, список линков, которые роутятся через данный линк. Это денормализация, заменяющая отдельную таблицу LinkRelations, чтобы избежать лишних накладных расходов. Не факт, что потребуется даже она, при описываемых объёмах данных.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Есть конечно. Узлы привязаны к географическим точкам. То есть, скажем, шкаф с оборудованием подключен к слоям A, B и D, это значит, что здесь три узла будет. I>>Скажем если ты гоняешь трафик на верхнем уровне между Москвой и Берлином, то на самом верхнем уровне всего два терминальных узла которые, на самом нижнем может быть пару тысяч и более транзитных узлов. S>Не вполне понятно, что на верхнем уровне. Прямой линк москва-берлин, или роут типа Москва-Калининград-Хельсинки-Берлин?
Угу.
I>>Еще тип пути — основной или резервный. Линков в пути может быть сколько угодно и даже могут цикл образовывать, обычно это простой цикл. S>Этот момент непонятен. Что значит "цикл", и как это работает?
Москва-Калининград-Хельсинки-Берлин-Варшава-Минск-Москва, как работает, это уже детали.
I>>Реально для утилизации оборудования и всяких схем резервирования обычно алгоритмы роутинга стараются дававать длинные пути. S>Какова средняя длина пути?
Это зависит от топологии, можно наверное 10-20 взять, я так навскидку не могу сказать, потому что уже ен работаю на этом проекте.
I>>Для одной конкретной задачи примерно так и будет, с поправкой на особенности роута, что я указал. Получить основной и резервный это частный случай. У каждого линка из любого пути будут в свою очередь так же основные и резервные пути. То есть, каждый слой роутится на нижележащие, и нужно скажем кликнув на линке верхнего уровня, получить полную картину на самом нижнем уровне, то есть, раскрутить весь роутинг по слоям. S>Ок, мы говорим о транзитивном замыкании. Которое вычисляется по данным, полный объём которых ложится в L1 cache процессора современного лэптопа. Всё ещё не понимаю, при чём тут RDBMS.
Ну ты же понимаешь, что приложение решает не одну эту задачу, потому данных намного больше. Один кусочек вполне может влезть в L1, но сначала надо сделать выборку. Может даже 100 байт хватит,но каким способом быстро выяснить, какие именно 100 байт тебе надо ?
I>>Подтянуть с сервера целую кучу данных крайне сложно, а после этого нужно еще визуализировать сеть и тд. S>Не понимаю проблемы подтянуть с сервера вашу "кучу данных". Полный объём — считанные мегабайты. Дельты, значит, будут исчисляться килобайтами. Здесь всё сводится к разработке структуры, удобной для двух целей:
Для одной задачи может и 100 байт быть. Но ведь приложение не решает одну единственную задачу. У линка например есть куча всяких свойств, ИД внезапно становится GUID, есть поля DateTime, есть всякие каналы, сегменты, парселы и тд и тд и тд и тд.
S>1. Скорость визуализации — это основное. S>2. Локальность изменений — это чтобы дельты были понятными (а не как в Rational Rose, где одно изменение в связях компонентов приводило к тысячам диффов в файле).
Вот обеспечить эту локальность очень трудно. Например ты захочешь удалить или изменить свойства узла. Внезапно оказывается, надо поудалять целую кучу приконнекченых к нему объектов. Например узел может присоединять только линки определенных типов. Меняешь тип узла, опаньки, все левые линки должны быть удалены, а до этого весь роутинг и тд и тд.
отдельный случай, топология все на всех — каждый узел связан со всеми остальными узлами. Как тут обеспечить локальность изменений, не ясно.
S>Технологию персистенса на серверной стороне нужно выбирать уже после того, как станет понятен протокол между клиентом и сервером. Вполне может подойти и RDBMS, но я этого понять не могу, пока нет полной постановки задачи.
Это понятно. Мне не понятно, какие еще данные тебе нужны. Реально выборка делается примерно так, если в объектной модели. Получить у узла весь генерируемый трафик, нужно по узлу получить все его линки, по каждому линку получить пути, каждого пути получить линки и все начинается заново и так до самого низа.
Или ноборотЮ посмотреть какие объекты роутятся через конкретный линк — получить все пути где есть этот линк, по ним получить все линки на верхнем уровне и тд и тд и тд.
Или такая вещь — обновить длину логических линков в соответствии с роутингом на физическом уровне. Надо раскрутить весь роутинг и пересчитать длину начиная с конца.
Типичный синдром инженегра, как я это про себя называю. Посмотрите хоть на сленговый термин «ГСМ» — увидите ту же картину. Ненависть и нежелание разбираться. Споров нет, п@#$болы с филфаков дискредитировали понятие «гуманитарий», но инженегроидность ничем не лучше. Такое же отклонение, только в другую сторону.
SV.>> Понадобилось, скажем, товар в корзину добавить — что, перегружать весь контент?
M>Можно и перегрузить. Разве вас кто-то тянет за хвост тащить ВЕСЬ контент магазина на одну страницу? Пусть на главной будут товары, а в отдельном (простом как тапок) окне — корзинка с товарами (занимающая от силы 2-5 кб). M>Как видите, сделать приложение не составляет труда, просто хомячкам с недельным курсом HTML+JS промыли мозги и они думают, что делают хорошие программы.
Как видит мир ижненегр: сидят, значит, хомячки и ваяют, как сердце прикажет. Откуда у них деньги, это инженегру неинтересно. «У тумбочке» берут, видимо.
В реальности над «хомячками» стоит менеджер и говорит, что и как должно работать. Чаще всего, им вообще приносят готовый .psd, и слава богу, если хотя бы слоевая разбивка есть. К нему дается набор комментариев, касающихся динамики (того самого AJAX'а). Откуда деньги у менеджера? А от клиентов, которые платят за все. И будьте уверены, что к ним прислушиваются, и вообще держат в фокусе внимания. Это значит, что встроенная корзина в конечном продукте появилась неспроста, а была проведена по всей цепочке от юзерских ожиданий до «хомячковой» реализации.
Теперь, что касается юзерских ожиданий. Юзеры под капот не смотрят, пока это их не затрагивает (и даже тогда многие не). Чтобы юзер открыл исходник страницы магазина, увидел там кучу Аякса, вместо топорного HTML'я и закрыл сайт — самим не смешно? Зато вот к дополнительным окнам юзер очень чувствителен. Я сам на днях понять не мог, почему у меня не открывается иллюстрация в интернет-магазине. Оказалось, открывается. Во внешнем окне. Которое я по случайности свернул, а не закрыл. А я, должен вам сказать, гораздо более многооконный, чем 98% юзеров. Вот поэтому все вменяемые магазины никогда не допустят такое решение до продакшен-сервера.
SV.>> А карты? С маршрутами, с вводом информации о пробках и так далее!
M>А зачем карты на HTML-ной странице? Совсем чтоль с ума посходили? Для карт нужна производительность + как можно более "нативный" интерактив (скажем, если у яблофилов нет ПКМ, для них нужно придумывать свой отдельный интерфейс). ЛЮБАЯ программа работает намного лучше, будучи написанной специально для конкретной ОС. То, что ленивая тварь за моником не хочет два раза писать код — это её проблемы. Но HTML+JS не победил мир, скорее наоборот — после браузерной горячки народ чешет хлюпало "чё ж мы такое писали?". Даже гугл с маньячной фобией мелкомягких технологий, и то не стал делать ведроид на хвалёных HTML/CSS/JS — там кругом Жаба. Дураки наверное, да?
Опять уши инженегра. Если бы он оторвался от студии и посмотрел по сторонам, на экономику, отношения людей, деньги, разве бы написал такое?
Картографическая информация такая ценная штука, что ее владельцы даже на возможность кэширования растрированных карт смотрели очень косо. Я не сильно в курсе, но, по-моему, еще несколько лет назад Яндекс не давал скачать кэш для мобильных аппов — владельцы карт не разрешали. Юзеры специально собирали этот кэш из кусочков и выкладывали на торренты. Что уж говорить про нативные аппы.
Другая сторона медали: до хрена юзеров никогда не запустит у себя бинарный софт рекламного агентства (коим и является Яндекс). Все же знают, что рекламные агентства собирают досье. С Пунто, например, скандальчик был, когда его прихватили на том, что он отправлял на сервер куски текстов под видом логов. Пусти козла в огорода, он неизвестно чего еще им наотправляет.
А тут оказывается, что во всем виновата ленивая тварь за моником. Она такие решения принимает по лени. Да ей такие решения и понюхать не дают. А не дают потому, что бизнес-цели она будет заменять... как там?.. «Для карт нужна производительность» — вот такими миражами.
Поскольку тут все ясно, я и отвечать не хотел. Времени жалко. Ответил потому, что кстати пришлось и ответ буду использовать в своих личных целях.
Пытается теперь смочь. С некоторым опозданием.
