Ada_Ru форум

Обсуждение языка Ада

Re: [ada_ru] Re: Совмещение языков

Оставить новое сообщение

Сообщения

Vladimir Teplouhov
Re: [ada_ru] Re: Совмещение языков
2007-03-14 02:03:13

13.03.07, Maxim Reznik<yeo@mail.zp.ua> написал(а):

On Sun, Mar 11, 2007 at 10:32:22PM +0000, Ivan Levashew wrote:

 

[skip]

> Вот ни с чем не спутаешь. Если Gtk или Qt на чужой платформе -

> то это видно.

>

Ну видно, ну и что? Конечного пользователя больше (ГОРАЗДО!!!)

интересует функциональность, чем какого цвета/вида стрелочка

на комбобоксе.

 

ну не скажи...

 

тут вообще интересное дело получается :)

получается что интерфейс тупо 1:1 переносить на другую платформу

вообще нельзя!

 

Вот смотри. Допустим у нас на PC на F8 удаление, а на F5 копирование.

И все к этому привыкли. А на другой платформе? А там может быть

все что угодно, хорошо если просто по-другому, а если окажется наоборот? :)

То-то будет весело - народ давит F5 и потом долго думает

акудажеэтовсеподевалось :)

 

Кстати, я тут счас только обратил внимание, что и сам пока пишу это

письмо по старой привычке(еще с turbo 5.5) вместо бэкапа через буфер

обмена уже несколько раз успел ткнуть F2 - хорошо еще что в этой программе на F2

ничего лишнего не висит...

 

Улавливаешь к чему клоню? :) Получается что вообще переносить все без

изменений нельзя!

(есть правда еще один вариант, кардинальный - изобрести какой-то один

суперправильный ;) (или просто дубовый, но обязательный для всех :) )

вариант интерфейса и всех на всех платформах переучивать под него...

Но я думаю пока это нам не грозит :) )

 

Итак, плавно скатываемся к вопросу, который уже как-то обсуждали - лучше

стандартизировать просто какой-то стык-интерфейс между собсно самим

программным модулем и, отдельно, его интерфейсом...

 

...

> Это не говоря о том, что, для Windows нет

> GPL версии x64 компилятора, а для Macintosh - i686 версии.

А что это кто-то использует? :) под win x64 и драйверов

пойди найди...

 

там где нужна скорость(CAD, графика и тп) 64 битные версии уже выпущены.

Для интерфейса правда не понимаю зачем применять более 8 бит :)

 

...

Файлы с русскими именами юзера как-то не используют, не жаловлись.

 

завидую :)

как бы наших отучить от русских имен...

 

Vladimir

PS ну дак че, получается что лепить интерфейс на дельфи не такая уж

и плохая идея? ;) Только не вижу смысла стыковать это все на уровне

программных вызовов в один блок кода вообще. Может быть есть какой-то

хороший способ обмена сигналами между отдельными программами? (типа

сама программа и ее интерфейс) Бонусов при таком подходе масса - от

управления из других модулей и отдельных программ, до возможности

прикрутить управление из скрипта или командной строки к любой GUI программе...

(сравните это с тем безобразием которое сейчас твориться под виндусом - когда

любая поделка может запросто залезти в винду и перепахать хоть все меню IE и др)

Vladimir Teplouhov <Vladimir.Teplouhov <at> gmail.com> writes:

 

ну не скажи...

 

тут вообще интересное дело получается :)

получается что интерфейс тупо 1:1 переносить на

другую платформу

вообще нельзя!

 

+1

 

Вот смотри. Допустим у нас на PC на F8 удаление, а на F5 копирование. И все к этому привыкли. А на другой платформе? А там

может быть

все что угодно, хорошо если просто по-другому, а если

окажется наоборот? :)

То-то будет весело - народ давит F5 и потом долго думает

акудажеэтовсеподевалось :)

 

На самом деле наоборот. Пользователи не так уж и часто

меняют платформу.

 

На PC удаление Del ;) А копирование через буфер обмена

или Drag'n'Drop.

 

F8 и F5 - это в клонах NC, но там свои правила. Большинство

клонов NC, которые я видел, честно стараются выдерживать

многолетние guidelines. На том же Маке вся разница только

в том, что F9 и F10 перекрыты Expose. Вместо них

Command-F9 и Command-F10.

 

Кстати, я тут счас только обратил внимание, что и сам

пока пишу это

письмо по старой привычке(еще с turbo 5.5) вместо бэкапа

через буфер

обмена уже несколько раз успел ткнуть F2 - хорошо еще

что в этой программе на F2

ничего лишнего не висит...

 

Это, опять же, проблема свитчеров. Им ничем, кроме создания

програм-хоббитов, не поможешь. Да и не надо.

Microsoft Office:mac, отдаю должное Microsoft, не является

прямой калькой MSO:Win. Но всё же :

Например, перемещение в начало строки -

на PC - Home

на Mac - Command-Left

Пользуется себе яблочник кучей програм, в них всё именно так.

А в Word:mac 2004 вдруг откуда-то Home. Вот именно, что

руки тянутся не к Home/End, неудобно только из-за одной программы менять привычки.

 

Улавливаешь к чему клоню? :) Получается что вообще

переносить все без

изменений нельзя!

 

Полноценный XPlatform интерфейс - это хороший уровень

абстракции + допиливания на конечных платформах.

Лично мне больше всего симпатичен Gecko engine.

У него пока что лучшие результаты по моему

user experience.

 

(есть правда еще один вариант, кардинальный -

изобрести какой-то один

суперправильный ;) (или просто дубовый, но

обязательный для всех :) )

вариант интерфейса и всех на всех платформах

переучивать под него...

 

Например, в Haxial KDX

так сделали. Внутренний движок полностью

заменяет нативный. Минимальный OS-dependent

функционал. Даже окна сворачиваются не так,

как все остальные в системе, а помещаются в

специальный док - окно.

 

В результате выглядит и работает идентично

везде. Дубовым этот подход не назовёшь,

интерфейс прикольный,

но у Haxial и аудитория соответствующая.

 

Итак, плавно скатываемся к вопросу, который уже

как-то обсуждали - лучше

стандартизировать просто какой-то стык-интерфейс

между собсно самим

программным модулем и, отдельно, его интерфейсом...

 

Да. И выбрать средства UI для каждой платформы отдельно.

Delphi, кстати, не лучший вариант.

В стандартной поставке много чего не хватает. Панели задач (как в Explorer). С системой взаимодействие не на лучшем уровне. Например,

Web-документ - это OLE коллекция элементов. Для работы с

коллекциями ничего, встроенного в язык, не предусмотрено, хотя и

есть OLE Automation.

Может быть, оно и правда к лучшему, что интеграция в MSVS, а не BDS идёт.

...

Это не говоря о том, что, для Windows нет

GPL версии x64 компилятора, а для Macintosh - i686 версии.

А что это кто-то использует? :) под win x64 и драйверов

пойди найди...

 

Сейчас в магазинах готовые полностью рабочие комплектации

продаются. Пройдёт время, и их доля ещё увеличится.

 

там где нужна скорость(CAD, графика и тп) 64 битные версии

уже выпущены.

Для интерфейса правда не понимаю зачем применять

более 8 бит :)

Прям хоть ставки делай - кто при таком подходе быстрее

освоит Win x64 : Delphi или GNAT?

 

Нет, правда, неприятно, когда software, претендующее

на статус 64-bit compatible, на поверку оказывается 64bit

лишь в *NIX. (В случае Delphi 64-бит только в .NET)

 

Ну а уж когда Google выдаёт рекламную ссылку

GNAT Pro for Mac "Complete Ada development environment for Mac OS" Ладно там GPL Edition, и бог с этим macada.org,

там энтузиасты, маки дорогие, не успели ещё

современным оборудованием запастись,

но то, что GNAT Pro, который типа "Complete", оффициально

UniBin не делает, при всём уважении,

looks a bit outdated.

Это если закрыть глаза на грядущий x64 Leopard.

 

Проблема, в общем-то, не новая, всё упирается в MingW,

в Cygwin, в них это ещё не решено. На GNAT-maid это косвенно

отражается, потому что GNAT runtime не нативные вызовы

использует, а из прослойки эмуляции POSIX.

То же самое с Unicode.

 

Файлы с русскими именами юзера как-то не используют,

не жаловлись.

 

завидую :)

как бы наших отучить от русских имен...

 

 

Ладно это ещё просто русские имена. А требуют-то именно

Юникод!

 

Хорошей демонстрацией настроений в обществе считаю

forum.farmanager.com :

1. Шутливый аватар zg

http://forum.farmanager.com/profile.php?mode=viewprofile&u=5

2. Не менее шутливая подпись Wave

Из года в год, от года к году

Мы ждали, ждали юникода,

Но не дождались, вашу мать...

Чего б ещё не подождать?

3. Мимолётная ирония k561ln7

О, я уже вижу как славно будут петь фанфары, как

с неба будут сыпаться лепестки красных роз, а

благодарные юзеры с благоговеньем будут падать

на колени расшибая их о каменные плиты площади

имени "far"-а... "ю-ни-кооод" - скандировала толпа,

и отголоски этого замечательного слова нежным

бризом раскатывались по долине "forum.farmanager.com"... :)

 

Кому охота такую судьбу своему приложению?

 

Да и тот же Borland несёт потери в странах,

где ANSI локаль отсутствует. Ну уж нет!

Надо что-то делать!

 

Я считаю, нужно начать с GNAT runtime. Если оно не будет

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

(бог с ним, с этим gcc, x86 на x64 эмулировать и ppc на i686 - совершенно разные по скорости вещи) уже легче будет переносить на Win x64.

 

Interix последних версий, кстати, имеет версию x64 (SUA).

Вот я всё и думаю, как бы этим воспользоваться.

 

В одиночку-то я GNAT runtime на WinAPI не перелопачу.

То ли на sf.net проект открыть?

Привет Владимир!

 

А как ты смотришь на библиотеку UI которая предоставляет для прикладного программера некий усредненный программный интерфейс а с другой стороны интегрируется в библиотеки UI для конкретной платформы? То есть является неким универсальным переходником между множеством библиотек UI и прикладной софтиной. То есть ты пишешь свою прикладную софтину 1 раз а потом собираешь ее с любыми библиотеками GUI которые поддерживает этот универсальный переходник.

 

 

Я думаю попробовать поделить на части немного в другом месте - на уровне

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

делить на части в самом тонком и простом месте - меньше будет связей и

связанных с этим сложностей), в этом месте и связей меньше и они проще.

 

Это конечно правильно, но для этого нужно знать особенности конкретной прикладной софтины. Универсальный интерфейс для всего так не сделаешь.

 

 

Пускай рисует менюшки, прочие шкуры ;) и обрабатывает клики сам

модуль интерфейса, причем делает внутри это как хочет(все равно на разных

платформах разные механизмы и даже способы обращения к системе).

Главное чтобы наружу выдавалась готовая комманда или ее код.

Ну например при нажатии меню file : save модуль интерфейса вызывает

SendCmd("SaveFile") или SendCmd(SaveFileCode),

 

Вот большинство таких команд и будут зависеть от прикладной софтины. На универсальность это IMHO не тянет.

 

дальше уже эта функция посылает код выбранной в меню команды программе

через какой-то интерфейс или даже как вариант по каналу связи.

 

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

 

Кстати

не обязательно

кликать - эта команда вполне может посылаться и по таймеру например,

если включен режим автосохранения...

Из бонусов - это легко разделить и запускать хоть на одной машине,

хоть по каналам связи управлять машиной в другом месте. Ну и самое

главное - всегда можно будет легко к любой программе прикрутить как GUI,

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

заменить внешний вид интерфейса конечно...

 

Да я двумя руками за этот шаблон проектирования. И сам стараюсь по возможности так делать. Но это ведь не про универсальный ЮИ совсем.

 

Структуру описания меню думаю тоже можно стандартизировать и прикрутить

к ней поисковик - нынче модно стало делать такую идиотскую структуру

меню, что проще искать в какое подменю эти уроды засунули нужную

функцию сразу поисковиком по ее названию или описанию...

 

ну с этим я совсем не согласен но спорить буду только в отдельной теме.

 

 

Можно еще вот какой подход обсудить: Создается некий DSL спефиально заточенный для описания ЮИ, а универсальный транслятор просто выполняет команды на этом языке. Такого добра конечно-же много но на универсальность особенно когда логический модуль и ЮИ работают на разных тачках связанных ненадежным каналом IMHO ни кто не тянет.

Alexander Molchevsky wrote:

Привет Владимир!

 

А как ты смотришь на библиотеку UI которая предоставляет для прикладного программера некий усредненный программный интерфейс а с другой стороны интегрируется в библиотеки UI для конкретной платформы? То есть является неким универсальным переходником между множеством библиотек UI и прикладной софтиной. То есть ты пишешь свою прикладную софтину 1 раз а потом собираешь ее с любыми библиотеками GUI которые поддерживает этот универсальный переходник.

 

Мой опыт показывает, что нет ничего хуже усредненного интерфейса. Многие подобные продукты выглядят просто потрясающе, когда начинается эмуляция какого-то виджета. Даже если внешний вид программы не клеется c общепринятым это проще переносится чем когда поверх стиля Windows появляется компонент в стиле Gtk. Выглядит как откровенная порнуха.

 

не обязательно

кликать - эта команда вполне может посылаться и по таймеру например,

если включен режим автосохранения...

Из бонусов - это легко разделить и запускать хоть на одной машине,

хоть по каналам связи управлять машиной в другом месте. Ну и самое

главное - всегда можно будет легко к любой программе прикрутить как GUI,

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

заменить внешний вид интерфейса конечно...

 

Да я двумя руками за этот шаблон проектирования. И сам стараюсь по возможности так делать. Но это ведь не про универсальный ЮИ совсем.

 

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

 

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

Привет Вадим!

 

А как ты смотришь на библиотеку UI которая предоставляет для прикладного

программера некий усредненный программный интерфейс а с другой стороны

интегрируется в библиотеки UI для конкретной платформы? То есть является

неким универсальным переходником между множеством библиотек UI и прикладной

софтиной. То есть ты пишешь свою прикладную софтину 1 раз а потом собираешь

ее с любыми библиотеками GUI которые поддерживает этот универсальный

переходник.

 

Мой опыт показывает, что нет ничего хуже усредненного интерфейса. Многие

подобные продукты выглядят просто потрясающе, когда начинается эмуляция

какого-то виджета. Даже если внешний вид программы не клеется c

общепринятым это проще переносится чем когда поверх стиля Windows

появляется компонент в стиле Gtk. Выглядит как откровенная порнуха.

 

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

 

Елсли присмотреться к тенденциям моды, то прослеживается стремление

именно к серединному решению. Оно обеспечивает максимальную гибкость -

всегда можно поменять лубую составляющую часть с минимальными затратами,

но в то же время оно, как правило, имеет и наибольший размер кода.

 

И наибольшую стоимость.

 

Можно еще вот какой подход обсудить: Создается некий DSL спефиально

заточенный для описания ЮИ, а универсальный транслятор просто выполняет

команды на этом языке.

А что если воспользоваться уже упоминавшимся Java Byte Code? ;)

 

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

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

 

Good luck!

Alexander Molchevsky

Привет всем!

Решил вставить и свои пять копеек :)

 

Alexander Molchevsky wrote:

Привет Вадим!

 

А как ты смотришь на библиотеку UI которая предоставляет для прикладного

программера некий усредненный программный интерфейс а с другой стороны

интегрируется в библиотеки UI для конкретной платформы? То есть является

неким универсальным переходником между множеством библиотек UI и прикладной софтиной. То есть ты пишешь свою прикладную софтину 1 раз а потом собираешь

ее с любыми библиотеками GUI которые поддерживает этот универсальный

переходник.

 

 

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

 

<Мастер-область>

<панель поиска/>

 

<дерево персонала>

...нечто, описывающее проблемную область древа...

</дерево персонала>

 

<что-там еще/>

</Мастер-область>

 

<Детальная область>

<Форма>

наполнение формы (в предметных терминах)

</Форма>

<Таблица>

описание таблицы, как вариант, <Бухгалтерская таблица> или некая другая..., можно определить пару десятков/сотен таких абстракций

</Таблица>

 

<Детальная область>

 

<Область управления>

<ок>

<записать>

<отменить>

и т.д.

<Область управления>

 

Идея вот в чем: Замечено, что все приложения одной предметной области, вне зависимости от среды стремяться выглядеть _похоже_ (не одинаково, но сходство есть). Сходство не в разнещении елементов и не в их виде, а в той информации, которую они представляют. Таким образом создаваю таку "библиотеку" мета-обьектов можно убить двух зайцев:

1. Повысить уровень абстракции (легче работать)

2. Упростить перенос.

 

Промежуточный слой должен заниматься трансляцией (можно в исходники Ады или Явы) подобного описания с учетом особенностей целевой платрофмы.

 

 

Знаю, сделать это сложно (если вообще возможно). Но было б прикольно.

 

Влад

Alexander Molchevsky wrote:

 

Елсли присмотреться к тенденциям моды, то прослеживается стремление

именно к серединному решению. Оно обеспечивает максимальную гибкость -

всегда можно поменять лубую составляющую часть с минимальными затратами,

но в то же время оно, как правило, имеет и наибольший размер кода.

 

И наибольшую стоимость.

 

Неприятный побочный эффект. :(

 

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

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

 

Если не Java, то чем не устраивают Gtk или Qt? Они предоставляют полный комплект виджетов и при этом вполне прилично и работают и выглядят на трех наиболее распространённых платформах: Win, X11, Mac.

 

Если программе необходимы сресдва продвинутого 2D рисования типа CAD со сложными задаваемыми пользователем примитивами, их выделением мышкой, управлением фокусом ввода, перетаскиванием, масштабированием и т.д. то Qt предоставляет очень серьёзное подспорье - виджет QGraphicsView. Его наличие и наличие виджетов QTableView, QListView, QTreeView (все из перечисленных поддерживают концепцию Model/View) в своё время толкнуло нас на разработку собственной связки Qt с Ada.

16.03.07, Vadim Godunko<vgodunko@rostel.ru> написал(а):

...

> софтиной. То есть ты пишешь свою прикладную софтину 1 раз а потом

собираешь

> ее с любыми библиотеками GUI которые поддерживает этот универсальный

> переходник.

>

Мой опыт показывает, что нет ничего хуже усредненного интерфейса. Многие

подобные продукты выглядят просто потрясающе, когда начинается эмуляция

какого-то виджета. Даже если внешний вид программы не клеется c

 

лучше вот что скажи по опыту - всегда ли можно реализовать одни(недостающие

функции в библиотеке которая физически исполняется на платформе) через другие?

 

я так понимаю что если базовые набор приметивов полный(есть хотябы

команда "нарисовать пиксель" :) ), то можно доказать что всегда через это

можно реализовать все что угодно. Тока может сильно тормозить :)

 

проблемы могут быть только когда при переходе к более низкому уровню

информация теряется. Ну например - на уровне текста все буквы известны точно,

а вот если перейти к его графическому изображению то уже потребуется как

миниум какой-то изврат с OCR чтобы получить из графики обратно букву...

(причем обратная задача кроме того что сложнее всей библиотеки,

еще и решается на всегда)

Лучше если этот буквенный уровень существует и доступен - тогда можно

например выкинуть графику вообще(при прорисовке окна например) без

сохранения, а при восстановлении экрана вычислить графическое

изображение текста по новой и тд и тп...

 

Я так понимаю аналогично текстам можно определить информацию

еще многих подобных типов.

 

общепринятым это проще переносится чем когда поверх стиля Windows

появляется компонент в стиле Gtk. Выглядит как откровенная порнуха.

 

в случае стыка на уровне кодов комманд таких проблем нет - сам GUI можно

рисовать в родной для платформы песочнице, никаках ограничений на вид

практически нет - главное чтобы в конце концов он выдал нужный код,

и не важно как его ввел юзер, кликом мыши, текстом или азбукой Морзе

если интерфейсная часть умеет ее распознавать...

 

...

> Да я двумя руками за этот шаблон проектирования. И сам стараюсь по

> возможности так делать. Но это ведь не про универсальный ЮИ совсем.

>

Война между тонкими и толстыми клиентами как известно привела к

появлению продвинутых клиентов. В зависимости от прикладной задачи могут

быть разумны самые разные решения. Плюсы есть и у жесткой интеграции GUI

с приложением и у полного их разделения.

Но истина лежит где-то по середине.

 

это уж точно :)

 

Елсли присмотреться к тенденциям моды, то прослеживается стремление

именно к серединному решению. Оно обеспечивает максимальную гибкость -

всегда можно поменять лубую составляющую часть с минимальными затратами,

но в то же время оно, как правило, имеет и наибольший размер кода.

 

>

> Можно еще вот какой подход обсудить: Создается некий DSL спефиально

> заточенный для описания ЮИ, а универсальный транслятор просто выполняет

> команды на этом языке.

А что если воспользоваться уже упоминавшимся Java Byte Code? ;)

 

не знаю причем тут java, но на возможность применения интерпретации

я уже вроде как-то намекал. Скорость тут(а тем более 64 бита ;) ) для

интерфейса при нынешних процессорах совсем не нужны, зато интерпретация

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

Все что угодно, вплоть до самоизменяющихся программ :)

Грубо говоря так - например, вместо кодов операций в байткоде могут

быть коды более высокого уровня: описание какого-то граф объекта

или окна, допустим комманда загрузки кода HotKey в соотв таблицу

движка и тд и тп.

Кстати DSL описания интерфейса может почти 1:1 конвертироваться в такой код,

ну или, как вариант, возможно все вплоть до прямого исполнения сразу прямо

текстовки самого языка - все равно даже современные навороченные

компиляторы занимают всего несколько десятков КБайт кода(TP 5.5 60 с

чем-то кил,

да и сам новый gnat не сильно больше :) В любом случае то дерьмо которое

генерят современные поделки для интерфейсов занимает обычно гораздо больше),

так что интерпретатор или транслятор DSL не думаю что будут больше...

Да и к тому-же на DSL программа будет всего несколько строчек,

так что скорость компиляции значения не имеет и можно все слепить

по-быстрому самыми приметивными, но простыми и понятными методами,

так что писанины не так много как в хорошем компиляторе...

В общем тут есть над чем подумать - главное не забывать что скорость и тп

тут совсем не обязательны :)

 

Vladimir

PS что-то припоминаются первые графические(еще векторные) дисплеи начала 70х,

дисплейные файлы и тп ;)

16.03.07, Vladyslav Kozlovskyy<dbdeveloper@rambler.ru> написал(а):

...

Предлагаю совсем уж фантастический вариант: отталкиваться не от

абстракции юзер-интерфейса и виджетов а от более высоких абстракций,

 

подобная "фантастика" делалась еще на IBM 360

конечно не для интерфейсов(тогда это не актуально было :) ),

для задач посерьезней вроде мат. аналитики и тп

 

правда это уже немного офтопик :)

(Ада алгоритмический язык, а это уже не совсем алгоритмический подход)

 

...

Идея вот в чем: Замечено, что все приложения одной предметной области,

вне зависимости от среды стремяться выглядеть _похоже_ (не одинаково, но

сходство есть). Сходство не в разнещении елементов и не в их виде, а в

 

кстати

идейка :)

а что если текстовый редактор заменить на че-нить вроде БД?

то есть сразу задать какой-то шаблон программы(и писать будет легче - а то

всегда вспоминать приходиться с чего должна начинаться и кончаться

программа и в каком порядке должны идти секции ;) ) - получиться эффект

как от "меню" или генератора, когда только какбы отвечаешь только на вопросы...

 

той информации, которую они представляют. Таким образом создаваю таку

"библиотеку" мета-обьектов можно убить двух зайцев:

1. Повысить уровень абстракции (легче работать)

2. Упростить перенос.

 

угу

 

можно еще оптимизатор зафигачить на уровне аналитического

преобразования самого исходника программы...

 

Промежуточный слой должен заниматься трансляцией (можно в исходники Ады

или Явы) подобного описания с учетом особенностей целевой платрофмы.

 

 

Знаю, сделать это сложно (если вообще возможно). Но было б прикольно.

 

вполне реально

если конечно не гоняться за 64 битами в интерфейсе или за скоростью gnat ;)

 

Vladimir

Vladimir Teplouhov wrote:

 

лучше вот что скажи по опыту - всегда ли можно реализовать одни(недостающие

функции в библиотеке которая физически исполняется на платформе) через другие?

 

я так понимаю что если базовые набор приметивов полный(есть хотябы

команда "нарисовать пиксель" :) ), то можно доказать что всегда через это

можно реализовать все что угодно. Тока может сильно тормозить :)

 

Если есть пара "получить пиксель"/"нарисовать пиксель", то можной сделать всё. Но не нужно. Ибо идеи даже простейшего алгоритма компьютерной графики - рисования отрезка без антиалиасинга - могут свести с ума неподготовленного человека.

 

проблемы могут быть только когда при переходе к более низкому уровню

информация теряется.

Концепция всех современных GUI строится на идее преобразования только в одну сторону от данных приложения к картинке. Обратная задача считается просто не нужной.

 

 

в случае стыка на уровне кодов комманд таких проблем нет - сам GUI можно

рисовать в родной для платформы песочнице, никаках ограничений на вид

практически нет - главное чтобы в конце концов он выдал нужный код,

и не важно как его ввел юзер, кликом мыши, текстом или азбукой Морзе

если интерфейсная часть умеет ее распознавать...

 

Беда только в том, что современный GUI может иметь офигенную сложность. Взять, например, концепцию Model/View. Классое разделение между логикой программы (Model) и способом отображения данных (View). Но подчас нужно написать тучу кода. Например, делегаты - компоненты для отображения и редактирования элементов модели в виде. Если для простейших типов данных всё обычно просто, то для чего-то посложнее придётся писать код. И если его писать даже для трёх платформ, то сопровождение превращается в ад.

 

 

не знаю причем тут java,

Кто-то предлагал делать GUI на Java, а логику приложения - на Ada. Мне очень понравилась идея для случая использования созданного GUI на любой платформе.

16.03.07, Alexander Molchevsky<jolly-fellow@yandex.ru> написал(а):

Привет Владимир!

 

А как ты смотришь на библиотеку UI которая предоставляет для прикладного

 

положительно ;)

 

программера некий усредненный программный интерфейс а с другой стороны

интегрируется в библиотеки UI для конкретной платформы? То есть является

неким универсальным переходником между множеством библиотек UI и прикладной

софтиной. То есть ты пишешь свою прикладную софтину 1 раз а потом собираешь

ее с любыми библиотеками GUI которые поддерживает этот универсальный

переходник.

 

это похоже вариант переноса самого интерфейса, с сохранением внешнего вида

(по крайней мере тип точно не изменить, вид окошек/рамочек/пимпочек

теоретически из-за другой базовой библиотеки может стать немного другим)

 

> Я думаю попробовать поделить на части немного в другом месте - на уровне

> готовых комманд (с точки зрения проектирования по всем правилам выгоднее

> делить на части в самом тонком и простом месте - меньше будет связей и

> связанных с этим сложностей), в этом месте и связей меньше и они проще.

 

Это конечно правильно, но для этого нужно знать особенности конкретной

прикладной софтины. Универсальный интерфейс для всего так не сделаешь.

 

наоборот так проще - надо всего лишь только договориться о кодах и все,

дальше работа распареллеливается(причем в этом варианте можно и вообще

сменить тип интерфейса полностью - все равно ведь писать эту часть

каждый раз)

 

из минусов - интерфейсный кусок придется писать заново для каждой платформы

 

впрочем можно перенести и его, но с некоторыми изменениями для учета

особенностей платформ

 

> Пускай рисует менюшки, прочие шкуры ;) и обрабатывает клики сам

> модуль интерфейса, причем делает внутри это как хочет(все равно на разных

> платформах разные механизмы и даже способы обращения к системе).

> Главное чтобы наружу выдавалась готовая комманда или ее код.

> Ну например при нажатии меню file : save модуль интерфейса вызывает

> SendCmd("SaveFile") или SendCmd(SaveFileCode),

 

Вот большинство таких команд и будут зависеть от прикладной софтины. На

универсальность это IMHO не тянет.

 

коды не проблема - можно просто задать таблицей или файлом

 

вот что сам внешний вид(и тип) для разных программ может отличаться

это да - тогда

придется каждый раз писать свою программу

 

> дальше уже эта функция посылает код выбранной в меню команды программе

> через какой-то интерфейс или даже как вариант по каналу связи.

 

А это уже протокол передачи данных а не программный интерфейс. Тут

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

соединения, секюрити, разделением юзеров и т.д. Короче протоколы

проектируются несколько по другому.

 

ничего сложного - обычно это описывается автоматом состояний

 

...

> Структуру описания меню думаю тоже можно стандартизировать и прикрутить

> к ней поисковик - нынче модно стало делать такую идиотскую структуру

> меню, что проще искать в какое подменю эти уроды засунули нужную

> функцию сразу поисковиком по ее названию или описанию...

 

ну с этим я совсем не согласен но спорить буду только в отдельной теме.

 

а меня это больше всего достает в программах :) :(

особенно если вместо человеческих надписей лепят какие-то дурацкие картинки,

а потом как дурак наводишь мышь на каждую чтобы найти нужное название,

лучше уж я сразу наберу на клавиатуре что надо(при этом поисковик может

искать и по неточному названию, и по описанию)...

 

 

 

Можно еще вот какой подход обсудить: Создается некий DSL спефиально

заточенный для описания ЮИ,

 

как думаешь, что(примерно) должен содержать такой язык?

(и то-же надо спросить у тех кто вплотную работал с X и либами для него)

 

а универсальный транслятор просто выполняет команды на этом языке.

 

тут возможны разные варианты - от тупого кодирования 1:1 и передачи

получившейся структуры данных движку(кстати вместо текстового редактора

и послед. синт анализа можно и сразу набивать БД какого-то соотв формата,

кстати думаю что это будет легче чем заучивать все команды и синтаксис языка),

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

на уровне вплоть до самого алгоритма...

 

Такого добра конечно-же много но на универсальность

особенно когда логический модуль и ЮИ работают на разных тачках связанных

ненадежным каналом IMHO ни кто не тянет.

 

да не, TCP/IP уже изобрели, так что ничего сложного :)

Другой вопрос что это не протокол, а какая-то пионерская глюкавая поделка,

практически не работающая на плохих каналах связи... Так что сложность

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

впринципе все для этого готовое есть.

 

Vladimir

17.03.07, Vadim Godunko<vgodunko@rostel.ru> написал(а):

Vladimir Teplouhov wrote:

>

> лучше вот что скажи по опыту - всегда ли можно реализовать

одни(недостающие

> функции в библиотеке которая физически исполняется на платформе) через

другие?

>

> я так понимаю что если базовые набор приметивов полный(есть хотябы

> команда "нарисовать пиксель" :) ), то можно доказать что всегда через это

> можно реализовать все что угодно. Тока может сильно тормозить :)

>

Если есть пара "получить пиксель"/"нарисовать пиксель", то можной

сделать всё. Но не нужно. Ибо идеи даже простейшего алгоритма

компьютерной графики - рисования отрезка без антиалиасинга - могут

свести с ума неподготовленного человека.

 

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

(если ее где-то нету на какой-то платформе)

 

то есть она если есть в базовом наборе платформы, то хорошо

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

ну или стараться не использовать такие функции которые есть не на всех

платформах

 

 

> проблемы могут быть только когда при переходе к более низкому уровню

> информация теряется.

Концепция всех современных GUI строится на идее преобразования только в

одну сторону от данных приложения к картинке. Обратная задача считается

просто не нужной.

 

это понятно

 

это если по уму :)

а работать приходится с тем что есть

 

 

> в случае стыка на уровне кодов комманд таких проблем нет - сам GUI можно

> рисовать в родной для платформы песочнице, никаках ограничений на вид

> практически нет - главное чтобы в конце концов он выдал нужный код,

> и не важно как его ввел юзер, кликом мыши, текстом или азбукой Морзе

> если интерфейсная часть умеет ее распознавать...

>

Беда только в том, что современный GUI может иметь офигенную сложность.

 

вот и я про то-же

 

Взять, например, концепцию Model/View. Классое разделение между логикой

программы (Model) и способом отображения данных (View). Но подчас нужно

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

редактирования элементов модели в виде. Если для простейших типов данных

всё обычно просто, то для чего-то посложнее придётся писать код. И если

его писать даже для трёх платформ, то сопровождение превращается в ад.

 

и сопровождение тоже

и ошибки из-за потери синхронизации

 

>

> не знаю причем тут java,

Кто-то предлагал делать GUI на Java, а логику приложения - на Ada. Мне

очень понравилась идея для случая использования созданного GUI на любой

платформе.

 

я не делаю принципиальной разницы между дельфи и жабой - я же сразу

сказал что любая песочница которая есть на платформе готовая подойдет

 

конечно если реализация жабы есть и там и там, то ее выбрать некоторый

смысл есть

 

а что делать с той самой сложностью? Это же придется все равно как-то

взаимодействовать с этой песочницей - вот это и хотелось бы избежать,

чтобы была возможность вообще с ней не ковыряться

 

Vladimir

Vladimir Teplouhov wrote:

17.03.07, Vadim Godunko<vgodunko@...> написал(а):

 

не знаю причем тут java,

Кто-то предлагал делать GUI на Java, а логику приложения - на Ada. Мне очень понравилась идея для случая использования созданного GUI на любой платформе.

 

Я, это был я. :-) Хотя сейчас мне хочется вдарится в экстрим на написать это на аде с компиляцией под jvm.

 

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

 

Я мало знаком с дельфи, но сомневаюсь что там есть аналог java web

start. Обычно как делают "кросплатформенные" приложения. На ftp сервере

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

накомпилять девелоперам. Юзер должен скачать, установить, следить за

обновлениями версий программы и зависимых библиотек, а если не нашел

бинарников, то пересобрать из сорсов.

 

Джава здесь выигрывает простой использования такого интерфейса (при

наличии уже установленной jre). Юзеру достаточно пойти по ссылке (общей

для всех платформ), дальше ему все поставится да еще автоматический

будут отслеживаться обновления, причем для него совершенно прозрачно. Он

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

 

Верну я обсуждение к теме совмещения языков. :-)

 

Вопрос по JGNAT будущего, сам я с ним

еще не игрался и легче спросить чем копать документацию. :-) Там

же палка о двух концах получается. Можно будет ада сорсы скомпилить в

java bytecode и слинковать с java библиотекой, например с JDBC. А можно

будет с помощью gcj скомпилить java библиотеку в dll и слинковаться

после компиляции аda сорсов обычным GNAT'ом. Эта ситуация будет например

если создавать библиотеку persistance objects на база реляционной БД и

эта библиотека будет использоваться как jvm клиентами так и сервером. Вопрос в том, будет при вашем JGNATe один и тот же код ада работать при обоих подходах? Или в зависимости от вида

линковки надо будет все это обрабатывать напильником?

 

 

-- Olleg Samoylov

Вопрос по JGNAT будущего, сам я с ним

еще не игрался и легче спросить чем копать документацию. :-)

 

Мне чтобы ответить ее тоже придется копать, поскольку это вне моей области ответственности. И к тому же мои знания джавы ограничены примерно тем, что есть такой сорт кофе :) Поэтому лучше избежать испорченного телефона ;)

ВФ

Vladyslav Kozlovskyy <dbdeveloper <at> rambler.ru> writes:

 

Предлагаю совсем уж фантастический вариант:

отталкиваться не от

абстракции юзер-интерфейса и виджетов а от более

высоких абстракций,

например

 

<Мастер-область>

<панель поиска/>

 

<дерево персонала>

...нечто, описывающее проблемную область древа...

</дерево персонала>

 

<что-там еще/>

</Мастер-область>

 

<Детальная область>

<Форма>

наполнение формы (в предметных терминах)

</Форма>

<Таблица>

описание таблицы, как вариант, <Бухгалтерская

таблица> или некая

другая..., можно определить пару десятков/сотен

таких абстракций

[...]

</Таблица>

 

<Детальная область>

 

<Область управления>

<ок>

<записать>

<отменить>

и т.д.

<Область управления>

 

[...]

Идея вот в чем: Замечено, что все приложения одной

предметной области,

вне зависимости от среды стремяться выглядеть

_похоже_ (не одинаково, но

сходство есть). Сходство не в разнещении елементов и

не в их виде, а в

той информации, которую они представляют. Таким

образом создаваю таку

"библиотеку" мета-обьектов можно убить двух зайцев:

1. Повысить уровень абстракции (легче работать)

2. Упростить перенос.

[...]

Промежуточный слой должен заниматься трансляцией

(можно в исходники Ады

или Явы) подобного описания с учетом особенностей

целевой платрофмы.

 

+10

 

Развиваю идею :

из этого описания интерфейса с помощью XSLT создаётся

XML, содержащий описание UI уже для конечной платформы,

(у каждой платформы своя XML схема)

а там у каждой платформы движок отображает в родные

элементы управления.

 

При таком подходе (ключевое слово XSLT) проще дорабатывать

абстракцию, т. к., с одной стороны, всего не предусмотришь,

в XSLT добавить всегда можно,

с другой стороны, появляется легальный способ использовать

фичи, уникальные только для одной платформы.

17.03.07, Olleg<olleg_s@mail.ru> написал(а):

Vladimir Teplouhov wrote:

> 17.03.07, Vadim Godunko<vgodunko@rostel.ru> написал(а):

 

>>> не знаю причем тут java,

>> Кто-то предлагал делать GUI на Java, а логику приложения - на Ada.

>> Мне очень понравилась идея для случая использования созданного GUI

>> на любой платформе.

 

Я, это был я. :-) Хотя сейчас мне хочется вдарится в экстрим на написать

это на аде с компиляцией под jvm.

 

припоминается старый анекдот:

- доктор, я буду жить?

- а смысл?

;)

 

впринципе прикрутить к jgnat хоть все жабовские либы проблем нет(там специально

сделано все для этого), но в этом случае писанины будет еще больше чем

сразу писать на жабе(сама задача + скрещивание). А главное даже не это - тогда

придется разбираться в этих жабовских песочных баблиотеках, а это меня например

совсем не прикалывает... К тому-же отладки ожидается гораздо больше -

все жабины

глюки + еще от скрещивания. Вот если бы всю эту муру выделить и засунуть

в один какой-то проект чтобы написать и отладить его всем миром один раз,

вот тогда бы другое дело...

 

да, и чую что похоже придется затронуть еще один важный вопрос - это затраты

на проект(время), сроки реализации и будет ли он вообще доведен до ума

до того как станет не актуальным :)

(хотя подозреваю что для некоторых это "мелоч" ;) )

Проще говоря, надо еще думать как сделать это проще,

если конечно есть желание что-то сделать а не только поболтать :)

 

 

> я не делаю принципиальной разницы между дельфи и жабой - я же сразу

> сказал что любая песочница которая есть на платформе готовая подойдет

 

Я мало знаком с дельфи, но сомневаюсь что там есть аналог java web

start. Обычно как делают "кросплатформенные" приложения. На ftp сервере

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

накомпилять девелоперам. Юзер должен скачать, установить, следить за

обновлениями версий программы и зависимых библиотек, а если не нашел

бинарников, то пересобрать из сорсов.

 

тоже вариант :)

 

но прикол интерпретаторов в том что можно исполнять один и тот-же код

на разных платформах. Хотя куча проверок в коде на тип платформы

и запуск различных веток подпрограмм тоже не очень-то красиво :)

Впрочем все равно лучше один case на 10 вариантов всего в 1 небольшом

программном модуле, чем клонирование всего проекта в 10 вариантах,

ну а небольшое увеличение кода нынче не так критично...

 

...

Верну я обсуждение к теме совмещения языков. :-)

 

Вопрос по JGNAT будущего, сам я с ним

 

что-то современные тенденции сильного усложнения языка и компилятора

мне не очень нравятся, хотя впринципе понятно почему они вынуждены так делать

 

как по мне дак думаю лучше придерживаться 83го и 95 стандартов с миниумом

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

всяких компиляторов компилятров и тд и тп

 

Vladimir

PS кстати, о новых компиляторах :) Кто-нить уже выкачал и собрал это

все в одну

кучу(я так понимаю что кроме самой Ада тут еще и все по дельфи, жабе и всему

остальному не плохо бы иметь в коллекции)? А то у нас тут всвязи с

безвременной

кончиной ;) ночной халявы на РОЛ-20 и траффиком по ~ 2 руб мег во всех местных

лохатронах под названием ADSL (в общем виде - "быстрый интернет") с оплатой

по траффику совсем кисло стало...

Это я намекаю - может быть и тут постнет(tm ;) ) организуем?

(CD/DVD RW почтой и нет проблем - рублей 10 на пересылку письмом)

Sat, 17 Mar 2007 10:06:50 +0600, "Vladimir Teplouhov" <Vladimir.Teplouhov@...> писал(а):

 

17.03.07, Olleg<olleg_s@...> написал(а):

Vladimir Teplouhov wrote:

> 17.03.07, Vadim Godunko<vgodunko@...> написал(а):

 

>>> не знаю причем тут java,

>> Кто-то предлагал делать GUI на Java, а логику приложения - на Ada.

>> Мне очень понравилась идея для случая использования созданного GUI

>> на любой платформе.

 

Я, это был я. :-) Хотя сейчас мне хочется вдарится в экстрим на написать

это на аде с компиляцией под jvm.

 

припоминается старый анекдот:

- доктор, я буду жить?

- а смысл?

;)

 

 

Мне кажется что проблема GUI , лежит в средстве автоматизации независивом от платформы и интегрированном в средства разработки для языка Ada, например в GNAT GPS.

 

Если делать свое, то нужно исходить из семиуровневой модели взаимодествия систем ISO. Начиная с GKS (Graphic Kernel System)- если кто помнит разрабатывался такой стандарт в 80-х годах. Далее по модели ISO.

 

With best regards Sergey Kirkorov

 

 

---

От каждого по способностям - каждому по кабинету!

Подробности на http://press.tut.by/2341.html

телефоны Салона в Минске: 226-03-05, 226-03-06. http://www.pro-trade.by

Вот и думаю. Поскольку люди здесь все умные, могу повторить постановку задачи, может кто что и посоветует. Заработываю я на жизнь не продажей программ, а как программист на подхвате у интернет провайдера. Исторический так случилось, что на заре интернета в нашей фирме было человек 5, профессиональная биллинговая стоила сорок килобаксов в результате у нас работает свое, самописное. Часть её написал я на java (interface), plpgsql (server), c++ (демоны). Часть её написал не я на php и perl. Путем естественной эволюции штука получилась крайне запутанной и неподвластной изменениям. Эволюционный тупик. Плюс наш провайдер вырос до размеров города и вопросы производительности стали вставать очень остро, хайтоповский amd64 сервер с нагрузкой справляется все хуже и приходится задумываться от ухода классической модели клиент/сервер к распределенной системе дабы разбросать нагрузку. Задача очень толстая, помимо основной работы по отъему денег у населения надо как-то интегрироваться с бухгалтерской системой типа 1С с одной стороны, а с другой уметь управлять разношерстным сетевым оборудованием (роутеры, коммутаторы, сервера, услуги оказываются по городской сети ethernet, не adsl, что сильно осложняет управление). Но я об этом здесь уже где-то писал.

 

В общем у меня есть рабочее время слабо контролируемое начальством. И желание сделать что-либо выдающееся, дабы было чем хвастаться.

 

Чтобы было проще хочется ограничится одним языком. На крайней случай двумя. На джаве программирую давно и по прежнему считаю что её jvm и библиотеки вне конкуренции для созданию толстых клиентов интерфейсов пользователей. И кроссплатформенность у меня востребованна, сам я под линуксом, остальные под виндами. + Очень хочется иметь клиент для мобильных телефонов, чтобы монтажники находясь у неработающего оборудования могли сами связаться с системой, например чтобы посмотреть/изменить топологию сети. Тонкий клиент влечет за собой замуты на javascript (типа Ajax) который не везде работает и везде работает по разному, но тоже вариант.

 

С серверной частью тоже все не просто. Вопрос производительности стоит остро. C++ меня не радует. Написать на java и скомпилить gcj это вариант, но здесь оффтопик. :-) Остаются варианты Ада сервер/Джава интерфейс или попытаться все сделать на Ада с компиляцией интерфейса под jvm. Создавать весь проект на одной языке будет наверное проще.

 

Вот так путем простых логических рассуждений я пришел к такому варианту. Хотя попробовать сделать +1 попытку реализовать все это я сейчас не решаюсь, купил толстую книжку Таненбаума "Распределенные системы, принципы и парадигмы" и хотел для начала её прочитать. Так что есть чем занять время до выхода JGNAT. :-)

-- Olleg Samoylov

Vladyslav Kozlovskyy wrote:

 

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

 

<Мастер-область>

<Детальная область>

<Форма>

наполнение формы (в предметных терминах)

</Форма>

<Таблица>

описание таблицы, как вариант, <Бухгалтерская таблица> или некая другая..., можно определить пару десятков/сотен таких абстракций

</Таблица>

 

<Детальная область>

 

Не надо изобретать html по новой. :-) xhtml вполне можно использовать как мета язык на базе xml для создания кроссплатформенных интерфейсов пользователя. :-) И это давно уже работает. :-)

 

-- Olleg Samoylov

Sergey Kirkorov wrote:

 

Мне кажется что проблема GUI , лежит в средстве автоматизации независивом от платформы и интегрированном в средства разработки для языка Ada, например в GNAT GPS.

 

GUI и IDE друг к другу никаким боком не лежат. Может иметь "вс ё водно" м иудобн, он он инеобходим, он идостаточн.

Olleg wrote:

Вот и думаю. Поскольку люди здесь все умные, могу повторить постановку задачи, может кто что и посоветует. Заработываю я на жизнь не продажей программ, а как программист на подхвате у интернет провайдера. Исторический так случилось, что на заре интернета в нашей фирме было человек 5, профессиональная биллинговая стоила сорок килобаксов в результате у нас работает свое, самописное. Часть её написал я на java (interface), plpgsql (server), c++ (демоны). Часть её написал не я на php и perl. Путем естественной эволюции штука получилась крайне запутанной и неподвластной изменениям. Эволюционный тупик. Плюс наш провайдер вырос до размеров города и вопросы производительности стали вставать очень остро, хайтоповский amd64 сервер с нагрузкой справляется все хуже и приходится задумываться от ухода классической модели клиент/сервер к распределенной системе дабы разбросать нагрузку. Задача очень толстая, помимо основной работы по отъему денег у населения надо как-то интегрироваться с бухгалтерской системой типа 1С с одной стороны, а с другой уметь управлять разношерстным сетевым оборудованием (роутеры, коммутаторы, сервера, услуги оказываются по городской сети ethernet, не adsl, что сильно осложняет управление). Но я об этом здесь уже где-то писал.

 

Какие задачи создают наибольшую нагрузку на оборудование?

 

Какие задачи требуют работы в реальном времени?

 

Как перекликаются эти задачи?

 

Вот так путем простых логических рассуждений я пришел к такому варианту. Хотя попробовать сделать +1 попытку реализовать все это я сейчас не решаюсь, купил толстую книжку Таненбаума "Распределенные системы, принципы и парадигмы" и хотел для начала её прочитать. Так что есть чем занять время до выхода JGNAT. :-)

 

Хорошая книжка.

Новое сообщение:
Страницы: 1 2

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти