Oberon space
General Category => Общий раздел => Тема начата: valexey от Июль 23, 2012, 06:05:47 pm
-
Неоднократно народ замечал что современные браузеры это странные вундервафли, и вообще говоря можно было бы сделать все проще. Ну, например на базе ББ в виде составного документа визуализировать информацию с сайтов.
Предлагаю попробовать решить частную задачу: как форум (например наш) мог бы выглядеть в ББ (то есть не встраивать рендеринг HTML в ББ, а просто в ББ прихоит вся необходимая информация - какие топики есть, какие в них сообщения и так далее, наша задача придумать правильный интерфейс для всего этого в рамках ББ).
То есть как визуально представить форум в BlackBox'e (не забываем про элементы управления/навигацию). Концепты (в виде набросков составных документов например, код пока никакой не нужен конечно же, либо вообще в виде картинок/скриншотов) приветствуются.
-
Не то слово. Я вот не могу понять, что может вызывать открытие браузера в 6-8 сек и, порой, дикие тормоза при рендере страниц на современных двух-четырех ядерных процах? И при этом, видео 1920*1080 60фпс - запросто.
-
Не то слово. Я вот не могу понять, что может вызывать открытие браузера в 6-8 сек и, порой, дикие тормоза при рендере страниц на современных двух-четырех ядерных процах? И при этом, видео 1920*1080 60фпс - запросто.
Ты этта... ББ в руках держать умеешь? Предлагай вериантики то :-)
Тут никаких навыков программизма не требуется вообще. Нужно лишь знать возможности ББ с его составными документами. У меня с ББ особо опыта нет, поэтому у меня все какие-то монстры получаются.
-
Задача давно была поставлена на Оберонкоре. Что характерно.
-
Задача давно была поставлена на Оберонкоре. Что характерно.
А решена? Ну, хотя бы один набросок интерфейса имеется?
-
Уточняю - я помню что там неоднократно этот вопрос поднимался. Но никакого практического выхлопа я не помню. То есть даже в виде концептов/картинок.
На всякий случая поясню еще раз - мне сейчас глубоко пофиг каким волшебным образом данные с форума попадают в ББ и в каком они формате. Будем считать что все необходимые данные уже есть. Нужно придумать удобный интерфейс/отображение их в ББ.
-
А чем принципиально может визуально отличаться интерфейс настольного приложения от веб?
Ведь используются те же элементы графического интерфейса: input, text area, select box, check box и пр. Только реализации клиентов форума будут отличаться.
Скорее всего, преимущество настольного клиента заключается лишь в скорости обмена данными.
Впрочем, не факт, что для этих целей я выбрал бы именно BB. Возможно, лучшим вариантом стала бы связка GPCP + Java/.NET.
-
А чем принципиально может визуально отличаться интерфейс настольного приложения от веб?
Ведь используются те же элементы графического интерфейса: input, text area, select box, check box и пр. Только реализации клиентов форума будут отличаться.
Смотри, в данной теме я таки говорю про интерфейс клиента для ББ. Отличие от браузерного интерфейса будут как минимум в потенциальной возможности многооконности интерфейса, кроме того возможности составных документов ББ и возможности современного html+css+js все же различны. Что-то проще сделать в составном документе ББ, что-то проще сделать в html.
Ну, например я например не помню что там у ББ с таблицами? Есть там такой элемент вообще?
Скорее всего, преимущество настольного клиента заключается лишь в скорости обмена данными.
Впрочем, не факт, что для этих целей я выбрал бы именно BB. Возможно, лучшим вариантом стала бы связка GPCP + Java/.NET.
Да скорость обмена данными будет примерно одна и та же (в конце концов ничто не мешает браузерный интерфейс форума сделать полностью на js, и по сути html передаваться не будет вообще). Преимущество в том, что если у человека уже установлен ББ (а я полагаю что значимой у части посетителей форума это так), то не нужно грузить еще жиррный браузер, достаточно подгрузить в ББ клиент (который МНОГО легче).
Но собственно вопрос не в целесообразности написания клиента в ББ, мне очень интересно как сделать удобный интерфейс для форума (например нашего) используя ББшные составные документы и парадигму "текст как интерфейс" (кстати, "текст как интерфейс" -- название не точное и достаточно безграмотное, более корректное название подобных интерфейсов -- "контент как интерфейс"). То есть мне интересен концепт интерфейса, а не конкретная реализация клиента.
Хотя, конечно, вполне может оказаться что через составной документ сделать это нормально не удастся и придется лепить конкретные классические формочки для удобной реализации в ББ.
-
Но собственно вопрос не в целесообразности написания клиента в ББ, мне очень интересно как сделать удобный интерфейс для форума (например нашего) используя ББшные составные документы и парадигму "текст как интерфейс" (кстати, "текст как интерфейс" -- название не точное и достаточно безграмотное, более корректное название подобных интерфейсов -- "контент как интерфейс"). То есть мне интересен концепт интерфейса, а не конкретная реализация клиента.
1) А ничего и не изменится - функциональность диктуется форумом -она достаточно простая (просмотр, редактирование), АКТИВНЫЕ элементы стандартны.
2) На скорость эта приблуда не повлияет-интерфейс рендерится браузером за доли секунды
3) Интерфейс форума проектировался под ЗАДАЧУ, а не под концепцию и по этому функционально оптимален.
4) Писать приблуду под ЭТОТ форум нецелесообразно(если не тащить js, то недостающую функциональность надо реализовывать кастомно)-а вдруг придется менять движок , тогда вся нае..ся медным тазиком.
Вывод-как ни крути, но речь Алексей БУДЕТ идти о рендерении HTML(хотите вы этого или нет)...
-
Но собственно вопрос не в целесообразности написания клиента в ББ, мне очень интересно как сделать удобный интерфейс для форума (например нашего) используя ББшные составные документы и парадигму "текст как интерфейс" (кстати, "текст как интерфейс" -- название не точное и достаточно безграмотное, более корректное название подобных интерфейсов -- "контент как интерфейс"). То есть мне интересен концепт интерфейса, а не конкретная реализация клиента.
1) А ничего и не изменится - функциональность диктуется форумом -она достаточно простая (просмотр, редактирование), АКТИВНЫЕ элементы стандартны.
Я вполне представляю как сделать например консольный интерфейс для форума :-) Не сказал бы что это будет особо удобным, но вполне юзабельным будет. Как сделать интерфейс в стиле составного документа ББ - не представляю. А хотелось бы представить.
2) На скорость эта приблуда не повлияет-интерфейс рендерится браузером за доли секунды
У меня - 1.4 секунды полная отрисовка (если верить хрому). Но не в этом дело.
3) Интерфейс форума проектировался под ЗАДАЧУ, а не под концепцию и по этому функционально оптимален.
Нет. См например почтовые клиенты. Задача у них одна, интерфейс сильно разный. Причем есть и веб интерфейсы, и десктопные и мобильные. С точки зрения интерфейсов интерфейс для форума не далеко от интерфейса для e-mail клиента ушел. Так что можно переформулировать задачу (от этого ничего не изменится) - как должно спроектировать в ББ интерфейс для e-mail клиента?
4) Писать приблуду под ЭТОТ форум нецелесообразно(если не тащить js, то недостающую функциональность надо реализовывать кастомно)-а вдруг придется менять движок , тогда вся нае..ся медным тазиком.
Вывод-как ни крути, но речь Алексей БУДЕТ идти о рендерении HTML(хотите вы этого или нет)...
Оно в этом случае навернется в меньшем колличестве мест, ибо данные на сторону клиентскую притекают по вполне стандартному простоколу не зависящему (или зависящему слабо) от форумного движка. Но еще раз - вопрос не в целесообразности, и не в тонкостях реализации клиент-серверного взаимодействия. Задача в том, чтобы сделать концепт интерфейса. Удобные и не слишком страшный концепт на базе ББшных составных документов.
-
Ну хз, с одной стороны, стандартный хтмл форум при каждом обновлении страницы тягает кучу ненужного технокала, от которого хотелось бы избавиться и шаги в эту сторону предпринимались используя аякс, но я видел только один форум на аяксе, и не скажу, что шибко вменяемый, но это было 2 года назад, может с того времени что-то изменилось. С другой стороны, браузер есть у всех и это как-то привычнее, например РСДН меня сильно напрягает - не по людски там сделано, если и ББ-шный клиент будет таким же, то нафикнафик
-
Ну хз, с одной стороны, стандартный хтмл форум при каждом обновлении страницы тягает кучу ненужного технокала, от которого хотелось бы избавиться и шаги в эту сторону предпринимались используя аякс, но я видел только один форум на аяксе, и не скажу, что шибко вменяемый, но это было 2 года назад, может с того времени что-то изменилось. С другой стороны, браузер есть у всех и это как-то привычнее, например РСДН меня сильно напрягает - не по людски там сделано, если и ББ-шный клиент будет таким же, то нафикнафик
А у RSDN'a еще и офлайновые клиенты есть!
Короче, предлагайте как это можно сделать по людски на ББ :-)
-
Я вполне представляю как сделать например консольный интерфейс для форума :-) Не сказал бы что это будет особо удобным, но вполне юзабельным будет. Как сделать интерфейс в стиле составного документа ББ - не представляю. А хотелось бы представить.
Так же как и на обычном десктопе (только хуже -средства представления (контролы) примитивнее)
Нет. См например почтовые клиенты. Задача у них одна, интерфейс сильно разный. Причем есть и веб интерфейсы, и десктопные и мобильные. С точки зрения интерфейсов интерфейс для форума не далеко от интерфейса для e-mail клиента ушел. Так что можно переформулировать задачу (от этого ничего не изменится) - как должно спроектировать в ББ интерфейс для e-mail клиента?
Да. Нечего на них смотреть -различия (существенные) обусловлены либо экстра функциональностью, либо ограниченными ресурсами , либо особенностями ввода вывода портативных устройств. Также как и обычного десктопа- функциональность форума примитивна(концепция текст как интерфейс ничего существенного в данном случае не привносит).
-
Я вполне представляю как сделать например консольный интерфейс для форума :-) Не сказал бы что это будет особо удобным, но вполне юзабельным будет. Как сделать интерфейс в стиле составного документа ББ - не представляю. А хотелось бы представить.
Так же как и на обычном десктопе (только хуже -средства представления (контролы) примитивнее)
Нет. Я имел ввиду не использование чего-то вроде ncurses/ANSI-графики. Контролов не будет вообще.
Нет. См например почтовые клиенты. Задача у них одна, интерфейс сильно разный. Причем есть и веб интерфейсы, и десктопные и мобильные. С точки зрения интерфейсов интерфейс для форума не далеко от интерфейса для e-mail клиента ушел. Так что можно переформулировать задачу (от этого ничего не изменится) - как должно спроектировать в ББ интерфейс для e-mail клиента?
Да. Нечего на них смотреть -различия (существенные) обусловлены либо экстра функциональностью, либо ограниченными ресурсами , либо особенностями ввода вывода портативных устройств. Также как и обычного десктопа- функциональность форума примитивна(концепция текст как интерфейс ничего существенного в данном случае не привносит).
Расширяй кругозор :-) Например в BeOS в почтовом клиенте каждое сообщение - это обычный файл с расширенными атрибутами. Таким образом обычным Tracker'ом (искаробочным файловым менеджером) ты ходишь по своей почте и видишь кто когда тебе написал. Почтового клиента как такового (единая монолитная программа, как в маздае привыкли) там просто нет. Есть почтовый демон который почту проверяет и складывает файлики в нужный каталог, и есть радактор/просмотрщик одного конкретного сообщения. Все.
-
Нет. Я имел ввиду не использование чего-то вроде ncurses/ANSI-графики. Контролов не будет вообще.
то есть не будет ни рубрикации , ни табличного представления с сортировками , поиском , фильтрацией..
Ну... ну ;D
Расширяй кругозор :-) Например в BeOS в почтовом клиенте каждое сообщение - это обычный файл с расширенными атрибутами. Таким образом обычным Tracker'ом (искаробочным файловым менеджером) ты ходишь по своей почте и видишь кто когда тебе написал. Почтового клиента как такового (единая монолитная программа, как в маздае привыкли) там просто нет. Есть почтовый демон который почту проверяет и складывает файлики в нужный каталог, и есть радактор/просмотрщик одного конкретного сообщения. Все.
;D Не вижу противоречий с тем о чем я писал -в beos -реализована БАЗОВАЯ функциональность, контролы и метода работы с ними с точки зрения пользователя ничем не отличаются от винды, а на архитектуру, как вы сами сказали в данном приближении насрать...
-
Нет. Я имел ввиду не использование чего-то вроде ncurses/ANSI-графики. Контролов не будет вообще.
то есть не будет ни рубрикации , ни табличного представления с сортировками , поиском , фильтрацией..
Ну... ну ;D
Не путай представление с функционалом. Табличного представления не будет. Поиск, сортировка, фильтация - будет. Равно как и рубрикация.
Расширяй кругозор :-) Например в BeOS в почтовом клиенте каждое сообщение - это обычный файл с расширенными атрибутами. Таким образом обычным Tracker'ом (искаробочным файловым менеджером) ты ходишь по своей почте и видишь кто когда тебе написал. Почтового клиента как такового (единая монолитная программа, как в маздае привыкли) там просто нет. Есть почтовый демон который почту проверяет и складывает файлики в нужный каталог, и есть радактор/просмотрщик одного конкретного сообщения. Все.
;D Не вижу противоречий с тем о чем я писал -в beos -реализована БАЗОВАЯ функциональность, контролы и метода работы с ними с точки зрения пользователя ничем не отличаются от винды, а на архитектуру, как вы сами сказали в данном приближении насрать...
Ты с этим работал? :-) Я вот работал. Так вот, с точки зрения пользователя отличия значительны.
-
Не путай представление с функционалом. Табличного представления не будет. Поиск, сортировка, фильтация - будет. Равно как и рубрикация.
Не путаю. ;). Хотите посмотреть как это будет выглядеть в том виде про который вы говорите? - посмотрите документацию
ББ.
Ты с этим работал? :-) Я вот работал. Так вот, с точки зрения пользователя отличия значительны.
Реально нет - кажется в 98-99 я ставил эту систему в ознакомительных целях,и фичу эту наблюдал -впечатление - УГ (унылое говно), хотя для того чтобы написать письмо, вполне функциональное- мне уже тогда этого было слишком мало.
-
Реально нет - кажется в 98-99 я ставил эту систему в ознакомительных целях,и фичу эту наблюдал -впечатление - УГ (унылое говно), хотя для того чтобы написать письмо, вполне функциональное- мне уже тогда этого было слишком мало.
А что тебе еще надо было? Поиск? Он там есть.
-
А что тебе еще надо было? Поиск? Он там есть.
Функциональности outlook express'a тех времен.
-
А что тебе еще надо было? Поиск? Он там есть.
Функциональности outlook express'a тех времен.
Насколько я помню, функциональность Outlook Expressa ничем не превосходила стандартного пчелиного мылера тех времен, кроме поддержки nntp (ньюсгрупп). Для ньюсгрупп я использовал PineappleNews.
-
Гиперссылки + фолды... Т.е. похоже на веб-интерфейс, при этом в Аякс-варианте, плюс фолды.
-
Гиперссылки + фолды... Т.е. похоже на веб-интерфейс, при этом в Аякс-варианте, плюс фолды.
А можно набросок в виде документика BB?
Меня крайне смущают два момента:
1) Отсутствие таблиц в BB
2) При вставке объекта (например картинки) нет возможности тексту его "обтекать", то есть он натурально вставляется как здоровенная такая буква.
Соответственно просто повторить интерфейс форума не получится. Нужно что-то придумывать.
-
В Блэкбоксе была сделана попытка создать некоторое подобие минималистской настольной издательской системы (DTP). На деле же получился чуть более продвинутый WordPad. По сравнению с HTML+CSS ее возможности невелики.
Возможности встраивать объекты могут быть полезны как альтернатива флэшу и апплетам. Хотя база верстки слаба. Так что форум-клиент получится скорее всего убого.
-
В Блэкбоксе была сделана попытка создать некоторое подобие минималистской настольной издательской системы (DTP). На деле же получился чуть более продвинутый WordPad. По сравнению с HTML+CSS ее возможности невелики.
Возможности встраивать объекты могут быть полезны как альтернатива флэшу и апплетам. Хотя база верстки слаба. Так что форум-клиент получится скорее всего убого.
Значит надо, видимо, не тупо дублировать интерфейс, а слегка сменить "парадигму" интерфейса. В конце концов в BB мы можем использовать не один документ/окошко, а несколько. Ну и формочки есть на крайний случай.
-
А можно набросок в виде документика BB?
Меня крайне смущают два момента:
1) Отсутствие таблиц в BB
2) При вставке объекта (например картинки) нет возможности тексту его "обтекать", то есть он натурально вставляется как здоровенная такая буква.
Ну, сейчас нет времени накидывать, проектируя форумный ГУЙ, честно; тем более, что ГУЁм я сам очень давно не занимаюсь, коллеги занимаются.
Но по поводу того, как иметь таблицы - есть, например, вот такой "эмулятор таблиц", я делал когда-то, если нужно разметить бланк каким-то образом, использую: http://oberoncore.ru/bbcc/subs/omc/textcells
В принципе, вторая проблема, если речь идёт только об отображении, тоже решаема, за счёт размещения параллельно вложенных текстовых блоков.
-
Предлагаю попробовать решить частную задачу: как форум (например наш) мог бы выглядеть в ББ
Сколько-то годков назад я написал на ББ нечто вроде чата. Мы с братом опробовали его, на этом и заглохло. После смены компьютера я ББ забросил, так что прямо сейчас не помню где исходники. Когда через месяц выйду из отпуска могу поискать. Вообще, не советую связываться с ББ. Дело в том, что если делать по нормальному, то блэкбоксовский сетевой модуль отвечающий за TCP надо будет переписать; далее надо будет просто выкинуть и написать с нуля модуль Stores, а на него всё остальное завязано, ну и смысл? Опять же 32 бита и однопоточность. Нафиг, нафиг.
Вон под WPF на C# настрогать...
-
Предлагаю попробовать решить частную задачу: как форум (например наш) мог бы выглядеть в ББ
Сколько-то годков назад я написал на ББ нечто вроде чата. Мы с братом опробовали его, на этом и заглохло. После смены компьютера я ББ забросил, так что прямо сейчас не помню где исходники. Когда через месяц выйду из отпуска могу поискать. Вообще, не советую связываться с ББ. Дело в том, что если делать по нормальному, то блэкбоксовский сетевой модуль отвечающий за TCP надо будет переписать; далее надо будет просто выкинуть и написать с нуля модуль Stores, а на него всё остальное завязано, ну и смысл? Опять же 32 бита и однопоточность. Нафиг, нафиг.
Вон под WPF на C# настрогать...
Смысл в proof of concept (на базе составного документа фейс для изначально чисто вебного форума). А технического совершенства добиваться уже потом, возможно посредством других инструментов.
А что там с сетевой подсистемой? Вроде ничего особенного тут не требуется. Простейший tcp.
-
А что там с сетевой подсистемой?
Используется WinSockets допотопной версии и однопоточная она. Опрашивается раз в 50 миллисекунд (это цикл главного потока ББ).
Вот захочешь ты отправить вложение размером в несколько мегабайт... В худшем случае оно будет отправляться со скоростью 128 Кб за 50 миллисекунд (дефолтный размер сокетного буфера и период блэкбокса), то есть два с половиной мегабайта в секунду.
По уму надо следующие 128 Кб отправлять сразу же как только уедут предыдущие. Это может произойти уже через несколько микросекунд. То есть нужно либо блокирующий сокет и отдельный поток, либо асинхронный callback, который фактически опять и есть отдельный поток, но в блэкбоксе менеджер памяти однопоточный. Приехали. Придётся извращаться.
-
Сергей, в подсистеме Comm вообще нет своей логики опроса. Будет опрашиваться ровно столько, сколько раз Вы дёрнете за неблокирующий Stream.ReadBytes.
В неграфическом приложении, где Вы делаете свой главный цикл, не будет никаких 50 мс.
В далёком 2009-м мой веб-сервер на Винде на одноядерном проце на тесте с отдачей статики из памяти чуть-чуть обходил апач.
Но я не за Comm, я использую свои абстракции каналов-буферов, но внутри в качестве временной реализации всё равно сидел Comm, переписать было некогда...
Stores вообще никто не заставляет использовать в неграфическом приложении. У меня в серверных вещах практически ничего не используется из Framework.
-
В далёком 2009-м мой веб-сервер на Винде на одноядерном проце на тесте с отдачей статики из памяти чуть-чуть обходил апач.
Справедливости ради, аппач на статике не обойдет только ленивый калечный инвалид :-)
-
Я не говорю об этом как о супердостижении, но это было сделано без всяких усилий, за малое время. Простор для оптимизации внутри абстрагированной реализации большой.
-
Я не говорю об этом как о супердостижении, но это было сделано без всяких усилий, за малое время. Простор для оптимизации внутри абстрагированной реализации большой.
ok. Я вообще не вижу тут проблемы для обсуждаемого клиента - даже если вдруг у нас ограничение 2.5 Мб/сек, то этого вполне достаточно для оного клиента. Вся база (sql база без сжатия) сообщений сейчас порядка 30 Мб, то есть выкачать ВЕСЬ форум удалось бы за десяток секунд. А поскольку такая операция далеко не каждый день производится, и обычно там ну десяток сообщений прилетит, то проблемы я не вижу вообще.
-
Предлагаю попробовать решить частную задачу: как форум (например наш) мог бы выглядеть в ББ
Сколько-то годков назад я написал на ББ нечто вроде чата. Мы с братом опробовали его, на этом и заглохло. После смены компьютера я ББ забросил, так что прямо сейчас не помню где исходники. Когда через месяц выйду из отпуска могу поискать.
Вообще, было бы интересно глянуть.
(месяц отпуска... завидую! меня не отпускают на месяц. на две недели то не хотели отпускать).
Вон под WPF на C# настрогать...
А это я не умею и не могу. Да и не где :-) Могу под Cocoa на ObjC настрогать...
-
В неграфическом приложении, где Вы делаете свой главный цикл, не будет никаких 50 мс. ... Stores вообще никто не заставляет использовать в неграфическом приложении. У меня в серверных вещах практически ничего не используется из Framework.
Поздравляю. Ты тоже послал ББ в сад. Осталось послать туда же и его 32-битный однопоточный рантайм. Жаль что при этом от языка Component Pascal останется лишь декларация...
Кстати, ещё асинхронка в рантайме нужна при установлении TCP соединения (особенно когда удалённый сервер не отвечает). На время установления соединения либо поток блокируется (и поэтому нужно делать это из вспомогательного потока) или же об установлении соединения сообщается посредством callback опять же в другом потоке.
-
В неграфическом приложении, где Вы делаете свой главный цикл, не будет никаких 50 мс. ... Stores вообще никто не заставляет использовать в неграфическом приложении. У меня в серверных вещах практически ничего не используется из Framework.
Поздравляю. Ты тоже послал ББ в сад. Осталось послать туда же и его 32-битный однопоточный рантайм. Жаль что при этом от языка Component Pascal останется лишь декларация...
Но почему, остается почти голый компилятор КП и ББ, как нестандартная IDE (почти тоже что и в случае использования "джентльменского" набора от XDS для этой цели).
;) Хотя , конечно, припоминаются в этой связи щенячьи восторги Ильи по поводу "совершенства архитектуры фреймворка ББ" в коровнике ( в основном, потому что усомнившихся в этом гражданин эцилоп банил, а посты их резались).
-
Смысл в proof of concept (на базе составного документа фейс для изначально чисто вебного форума). А технического совершенства добиваться уже потом, возможно посредством других инструментов.
У меня мозги как-то иначе резонируют на подобную задачку. В первую очередь когда я думаю о программе "Форум", то возникает схема из нескольких модулей (смотри вложение), а уж чего там в гуе будет, как-то не интересно.
Во вложении набросок системы типа "Форум" а-ля микро-одноклассники или нано-фэйсбук. На полноценный фэйсбук (сто миллионов соединений) не потянет, а на 100-200 тысяч одновременных соединений -- запросто.
-
Смысл в proof of concept (на базе составного документа фейс для изначально чисто вебного форума). А технического совершенства добиваться уже потом, возможно посредством других инструментов.
У меня мозги как-то иначе резонируют на подобную задачку. В первую очередь когда я думаю о программе "Форум", то возникает схема из нескольких модулей (смотри вложение), а уж чего там в гуе будет, как-то не интересно.
Дык профдеформация же :-) Глянь первое сообщение топика, там задача была поставлена полностью: http://oberspace.dyndns.org/index.php/topic,292.msg6969.html#msg6969
Во вложении набросок системы типа "Форум" а-ля микро-одноклассники или нано-фэйсбук. На полноценный фэйсбук (сто миллионов соединений) не потянет, а на 100-200 тысяч одновременных соединений -- запросто.
Ну, если уж про схему говорить, то я не вижу смысла именно что для форума использовать реляционную базу данных (тем более если планируются большие нагрузки). Оно ж нормально не масштабируется раз, и работает весьма медленно (относительно современных NoSql и древних dbm) два. Ну и наконец вся моща реляционки с sql-запросами тут просто не нужна. Собственно всякие вконтактофейспалмы и используют NoSql.
И еще по схеме - на схеме указаня странные ограничения по 64К соединений у каждого балансера (в случае http, это будет, очевидно, какой-нибудь nginx), так вот, при таком сценарии использования нет ограничения в 64К соединений. Ограничение будет по файловым дескрипторам (то есть порядка 300k), Скажем xmpp-сервера спокойно на одной машине держат порядка 80-100к соединений без балансеров вообще. Подробней можно посмотреть тут: http://stackoverflow.com/questions/2332741/what-is-the-theoretical-maximum-number-of-open-tcp-connections-that-a-modern-lin
Ах, да, еще нюанс - http не требует постоянного поддержания соединения (собственно keep-alive это просто оптимизация), в обычном, не оптимизированном сценарии, tcp соединение рвется после каждого ответа сервера.
И да, думаю у меня не будет проблем на коленке без хитрой схемы наклепать сервер форума который мог бы на слабеньком vps выдержать какой-нибудь "хабраэффект".
-
Но почему, остается почти голый компилятор КП и ББ, как нестандартная IDE (почти тоже что и в случае использования "джентльменского" набора от XDS для этой цели).
;) Хотя , конечно, припоминаются в этой связи щенячьи восторги Ильи по поводу "совершенства архитектуры фреймворка ББ" в коровнике ( в основном, потому что усомнившихся в этом гражданин эцилоп банил, а посты их резались).
Фреймворк ББ - для настольных приложений. И для этапа разработки.
(Если "почти то же", то попробуйте чем-нибудь расширить тот же закрытый XDS, или вон Visual Studio. Напишите какой-нибудь элементарный плагинчик, шоб прочувствовать. Когда-то в 2005-м, когда только мы начинали использовать ББ, была возможность сравнить с написанием плагина для C++ Builder).
В высоконагруженных приложениях идёт другой режим работы с памятью - и вещи, написанные в расчёте на автоматическую сборку мусора, не катят. Про что здесь много говорят Сергей и Алексей. И многие, решающие подобные задачи, сейчас приходят к этому пониманию.
Идёт закономерный виток спирали развития - "отрицание отрицания", ручное управление, но на новом уровне, в герметичном языке.
Поскольку это даже в самом хорошо спроектированном случае несколько усложняет программирование, то для настольных нужд нет никаких причин отказываться от GC. И там Framework применим. Для тех же CASE-инструментов.
-
Но почему, остается почти голый компилятор КП и ББ, как нестандартная IDE (почти тоже что и в случае использования "джентльменского" набора от XDS для этой цели).
;) Хотя , конечно, припоминаются в этой связи щенячьи восторги Ильи по поводу "совершенства архитектуры фреймворка ББ" в коровнике ( в основном, потому что усомнившихся в этом гражданин эцилоп банил, а посты их резались).
Фреймворк ББ - для настольных приложений. И для этапа разработки.
Я это знаю - но тем не менее вы также в превосходной степени говорили и о таком использовании ББ (причем никто за язык вас не тянул).
-
Ну я же разрабатываю приложения того класса на ББ! Он является инструментом, средой, на этапе разработки. Просто большинство абстракций Framework как раз и ориентированы на GUI.
В чём противоречие?
Ну да, я использую в рантайме только КП, модифицированное ядро и свой фреймворк.
Но в чём "вина" ББ?
-
Фреймворк ББ - для настольных приложений. И для этапа разработки.
(Если "почти то же", то попробуйте чем-нибудь расширить тот же закрытый XDS, или вон Visual Studio. Напишите какой-нибудь элементарный плагинчик, шоб прочувствовать. Когда-то в 2005-м, когда только мы начинали использовать ББ, была возможность сравнить с написанием плагина для C++ Builder).
В высоконагруженных приложениях идёт другой режим работы с памятью - и вещи, написанные в расчёте на автоматическую сборку мусора, не катят. Про что здесь много говорят Сергей и Алексей. И многие, решающие подобные задачи, сейчас приходят к этому пониманию.
Не упоминай C++ Builder в суе! Его система плагинов - это же ужас-ужас. Плавали, знаем :-)
Да, и не следует смешивать понятия "не высоко нагруженное приложение" и "десктоп приложение". Многие десктоп приложения являются высоконагруженными (те же самые игры, обработка видео в любом виде (в том числе клиенты для видеозвонков), различные CAD'ы и не очень (3D studio max та же), ansys опять таки). Таже, не следует забывать о мобильных приложения - там тоже приходится бороться со сборщиком мусора (если он на данной платформе есть) - памяти мало (а свопа нет вообще), а главное - мало батарейки. Про микроконтроллеры я вообще молчу..
Таким образом выходит что GC без оглядок применим только на узком множестве задач, это те задачи, когда у нас доступных ресурсов в десятки раз больше чем требует задача сама по себе (причем ресурсы это не только память и процессор, но и энергия и время). И, безусловно, ББ как IDE на современных машинах как раз попадает в этот класс задач.
-
Тот же CAD, в общем-то, тоже. Никто не мешает там помусорить-помусорить, потом за полсекунды или даже секунду собрать...
-
Но в чём "вина" ББ?
Все дело в Вас, Илья и ситуации которая сложилась в коровнике (при попустительстве Инфо21) - когда наказывалась даже попытка разобраться с областью использования ББ. Яркий пример лажа с жаберлоггером акаШума - создание работающего но нах. ни кому не нужного приложения (вследствие ограничения технологии).
-
Тот же CAD, в общем-то, тоже. Никто не мешает там помусорить-помусорить, потом за полсекунды или даже секунду собрать...
Там объемы данных большие, такие же как на серверах по сути. Поэтому там это будет не секунда далеко. + если у нас сборщик мусора не компактифицирующий,то очень быстро напоремся на фрагментацию данных - память из за нее просто закончится.
Да, и периодические фризы (пусть даже всего на секунду) интерфейса пользователя сильно снизят производительность оного пользователя - работа начнет раздражать.
-
В высоконагруженных приложениях идёт другой режим работы с памятью - и вещи, написанные в расчёте на автоматическую сборку мусора, не катят. Про что здесь много говорят Сергей и Алексей. И многие, решающие подобные задачи, сейчас приходят к этому пониманию.
Идёт закономерный виток спирали развития - "отрицание отрицания", ручное управление, но на новом уровне, в герметичном языке.
Эрланг расчитан на создание высоконагруженного серверного ПО, и там сборщик мусора вполне справляется с работой.
Почему же там это катит, а в других языках -- нет?
-
В высоконагруженных приложениях идёт другой режим работы с памятью - и вещи, написанные в расчёте на автоматическую сборку мусора, не катят. Про что здесь много говорят Сергей и Алексей. И многие, решающие подобные задачи, сейчас приходят к этому пониманию.
Идёт закономерный виток спирали развития - "отрицание отрицания", ручное управление, но на новом уровне, в герметичном языке.
Эрланг расчитан на создание высоконагруженного серверного ПО, и там сборщик мусора вполне справляется с работой.
Почему же там это катит, а в других языках -- нет?
Во-первых там не некое обобщенное высоконагруженое приложение, а вполне конкретное (система массового обслуживания).
Во-вторых оный erlang под это заточен, то есть под конкретное применение. По сути erlang это эдакий DSL от эриксона. Для других задач erlang не применим.
Ах, да. Почему ты о них говоришь в единственном числе. :-) Там же у каждого процесса свой собственный сборщик мусора. (а процессов да, десятки и сотни тысяч).
-
Ах, да. Почему ты о них говоришь в единственном числе. :-) Там же у каждого процесса свой собственный сборщик мусора. (а процессов да, десятки и сотни тысяч).
Ну а как иначе-то? Это же не примитив типа .NET, естественно, что там должен быть собственный GC у каждого процесса... :P
-
... или вон Visual Studio. Напишите какой-нибудь элементарный плагинчик, шоб прочувствовать.
Вообще-то сайте http://visualstudiogallery.msdn.microsoft.com/ лежит уже 3302 плагинчика.
Попробуйте написать простенький плагинчик в ББ типа такого http://forum.oberoncore.ru/viewtopic.php?p=51289#p51289
-
Ну так это пример на задачу, которая выходит за сферу гибкости базовой модели (ББ-шного текста).
Я точно так же могу предложить задачу написать плагинчик для Студии, который поддержит внедрение прямо в исходник какого-нибудь графического объекта, схемы, с возможностью редактирования "по месту", по которой потом будет генерироваться код в это место.