Сказанное Вами побуждает меня попросить Вас сообщить новые подробности. Всё это воспринимается как задачка, при решении которой можно было бы проверить в деле много разных «гитик».
Ещё Иммануил Кант предостерегал от таких вопросов… К тому же, довольно трудно рассуждать о времени, когда само время «рождалось» и «разворачивалось». Мы мыслим линейно и… только в одну сторону, а представить себе, например, контрамоцию (по Стругацким), вообще, невозможно. Как это: жить, в обратную сторону? А как себе представить динамическую систему с двумерным временем? А дробная размерность тут предусмотрена?
Да, было бы неплохо посидеть на досуге и поразбирать этот заковыристый запрос. Неужели, в реальных приложениях «всё так плохо» (с запросами), или, всё-таки, структуры таблиц стараются такими, чтобы максимально упростить запросы?
И… что это за точки в тексте запроса:
"pr"."id" = "ufref3758_i16"."request"
Я немного отстал от жизни и мне требуется пояснить синтаксис.
У меня вызывает внутреннее противление приведённая в статье реализация функции
static int CheckModemConnection()
На первый взгляд, всё выглядит понятным. На это и рассчитано.
Возвращает 1, если параметры, связанные с модемным соединением изменились, и 0, если нет.
Насколько я помню, это традиционно для Си возвращать именно такие значения, чтобы в месте вызова можно было бы реализовать обработку для случая произошедших изменений. Было бы логичнее иметь в качестве кода возврата bool, но это же Си! (NB: надо свериться с последним стандартом!)
Далее, название функции: CheckModemConnection. А если придётся проверять ещё чего-нибудь, то надо будет писать отдельную функцию для вот этого самого чего-нибудь? Мне бы ужасно захотелось бы обобщить и иметь общую для всех функцию проверки. Даже, если в Си нет классов. (Всегда можно ввести.) К тому же, для того, чтобы иметь возможность проверять состояние, неплохо бы как-то формализовать сие понятие и сделать так, чтобы, например, пробегать по списку необходимых свойств в цикле, а не создавать длинное условие для оператора if.
В конце-концов, было бы крайне любопытно (и эффективно?) иметь текстовую строку, описывающую текущее состояние объекта, каждый символ которой связан с некоторым элементом описания модемного соединения. Делая простой проход по этой строке, можно было бы сразу получать ответ на нужный вопрос. А, если само символьное представление делать более сложным (XML?), то можно было бы автоматизировать выдачу диагностических сообщений (например, соединяя друг с другом строки состояния для различных элементов в единую строку).
До недавнего времени я думал также, как и Вы. Но, однажды, я представил себе другой мир. Но я не предлагаю изменить наш мир. Я всего лишь рассуждаю о разного рода возможностях. На мой взгляд, они есть.
Спасибо за Ваш довольно развёрнутый комментарий. Многое здесь нуждается не столько в ответе, сколько в дальнейшем размышлении, пополнении опыта и, скорее всего, приведёт к появлению новых статей. Отвечу, сейчас, только на самый главный (для себя) вопрос:
Вы серьезно думаете, что Интернет создали люди, которые не обдумывали никакие вопросы?
В основе всего всегда лежат какие-то идеи. Бывает, и довольно глубокие. Но! В действительности, реализуется далеко не всё и не так, как это должно и могло бы быть на самом деле. По сути, новая технология только после нескольких этапов своего развития доходит до того, что реализует некое подобие задуманного в самом начале. Вот, я и задумался над тем, что же это могло бы быть, если бы многие вещи, которые нам сейчас знакомы, были бы реализованы в самом начале и стали бы органической частью Интернета.
Если у Вас есть вопросы или вполне определённые претензии по содержанию, стилистике и по самой концепции, то, лучше, высказать их вслух. Если механизм обратной связи сработает правильно, то мне будет особенно приятно получить за следующую статью плюс от скептика. Значит, удалось убедить и его. Хорошее критическое замечание всегда ценно, поскольку заставляет посмотреть на те же вещи под другим углом или совершить переоценку ценностей, когда станут более интересными совсем другие вещи.
Вопросы происхождения знаний и вопросы авторского права я не рассматривал. О Википедии следует написать отдельную статью. А если вспоминать доинтернетовские времена, то… хочется спросить, почему так часто происходит, что приход новых технологий не даёт того безусловного, положительного результата, который мы, обычно, ожидаем от него?
Как ни странно, я именно это и имел виду: в WEB'е, почему-то, многие вопросы возникли «как бы» заново. Хотя сами проблемы и задачи были известны (и решались) до того. (Было бы неплохо, однажды, «вспомнить», как это было тогда, для ясности картины.) Вопрос в том и заключается, что
десятки лет существовали распределенные системы с клиентами разной степени «толщины», в которых давно и буднично решались многие вопросы
В таком случае, задам вопрос Вам. Если это так есть (а я это и предполагал, когда писал статью), то зачем понадобились WEB-странички?
Честно говоря, возникает желание заняться этой темой. Это важно и актуально. Но, кажется, что эта тема хорошо проработана, потому что про «мультиагентный подход» я слышу уже дано, а, значит, разработчиками уже выработаны какие-то оптимальные решения. Или, всё же, не совсем? Но разобраться в основах было бы очень любопытно.
Простите. А Вы не можете мне в двух словах объяснить, что такое «аллокаторы»? Систематическое изучение C++ у меня впереди, и я понимаю, что аллокаторы — это (наверное) какие специальные функции или конструкции, которые выделяют память. Или… это что-то вроде «умных указателей»? (если попал «пальцем в небо», то не отчаивайтесь, а, просто, расскажите своими словами, будет понятнее, потом, читать книжку, а я Вам «спасибо» скажу)))
Не стоит разводить здесь «холивар», особенно, если Вас об этом прямо попросил автор статьи.
Да и, вообще, все эти «холивары» изначально лишены всякого смысла. Хороший программист напишет хорошую программу на том языке, который он знает. Какой знает, так и знает. Но, уж, если знает, то знает хорошо. Плохой программист не знает ни одного языка и, соответственно, ни на одном языке не сможет ничего путного написать.
Так что, на этом, попрошу всякий «холивар» на Хабрахабре прекратить. Спасибо за понимание. ;-)
С цветом надо быть очень острожным. Одноцветные иконки довольно спокойно воспринимаются (не ребит в глазах). Это как с чёрно-белыми фотографиями: они (почему-то) оказываются информативнее цветных.
И… не надо никому желать гореть в адском пламени. Все там будем.
(в сторону) Интересно, а как можно нарисовать точный квадрат? Ведь, его надо будет рисовать прямоугольником. Там нужно использовать коэффициент искажения (aspect ratio?)…
1. Да, есть SOAP, XML-RPC, JSON REST и т.д. и т.п. Но вопрос не в том, что есть, а в том, что могло бы быть. На этот вопрос Вы не ответили.
2. CORBA была мною упомянута исключительно как пример технологии, которая, может быть, где-то сейчас и используется, но, в своё время, эта технология претендовала на очень многое. И, если бы, CORBA (или её более продвинутый аналог) хорошо развивалась, то, вполне возможно, SOAP, XML-RPC, JSON REST просто не появились бы по той простой причине, что все их функции были бы изначально встроены в единую технологию, и не надо было бы «городить огород». Но, это всё — не более чем предположение.
3. За безопасность локального приложения отвечает операционная система (ОС), и, по идее, именно ОС должна обеспечивать приложению что-то вроде «песочницы». А если само создание ОС будет нам гарантировать отсутствие вредоносного кода? Откуда, кстати, он появляется? Передаётся по сети? А зачем код передавать по сети? Всё должно быть и так уже установлено в ОС. Чего может не хватать распределённому приложению? Реализации каких-то специфических функций. Хорошо. Можно загрузить их с сайта, с которым Вы работаете. Но это должна быть рядовая операция установки программного обеспечения (ПО). Но, опять же, это всё — некое предположение о том, что «мир мог быть другим».
4. Если мы живём в мире, где WEB-приложений нет, то все приложения — локальные. Следовательно, все процессы обслуживаются рядовым ПО, то есть, самой ОС. Заметьте, единообразно! Стороннему приложению нужно, только задать обработчик. Но если документ, с которым Вы работаете, реализуется объектной моделью самой ОС, то внешнему сайту достаточно передать Вашей ОС карту переходов (от одних документов к другим).
5. И, наконец, самый тяжёлый вопрос: а зачем нам браузер? Большая часть содержимого Интернета хорошо укладывается в формат базы данных, и для просмотра этого содержимого вполне достаточно стандартных визуальных компонентов ОС. Зачем Вам заходить в браузере на нужный Вам сайт со списком, там, «чего-нибудь» (новостей, статей, обсуждений, товаров, книг), если Вы должны зайти у себя в ОС в приложение «База данных», где Вам будет достаточно подключиться к соответствующему узлу и получить от него требуемый Вам набор данных? Зачем нам страничный доступ к Ютьюбу, если у нас есть свой плеер (который всегда работает!), и нам нужно, только, иметь ссылку на источник потока?
Вот таблица браузеров и их поведения:
Об этом и речь! Строго говоря, должен быть только один браузер, реализованный в самой ОС: с единой документной моделью и гарантирующим всем приложениям единообразное поведение.
Без сомнений, по мере развития браузеров и роста веба, механика прокрутки станет даже более сложной и изощрённой.
Почему нужно всё только усложнять, а не упрощать? Разве грамотное применение информационных технологий не заключается в создании простых и прозрачных схем взаимодействия?
Сама же обсуждаемая здесь статья довольно любопытна. Спасибо за перевод. Но, разве, есть что-то предосудительное в том, чтобы пытаться представить себе другой мир, в котором таких проблем (вроде описываемых в статье) попросту нет, поскольку «мир другой», и в этом «другом мире» совершенно другая архитектура построения приложений?
Интересно, как это всё выглядело бы в случае, если вместо языков разметки, браузеров и скриптов, были бы развитые протоколы передачи структурированных данных (в виде надстройки стека протоколов над TCP/IP и HTTP) и удалённого вызова процедур? Была же CORBA. Вот, зачем, её ней(т)рализовали?
Чем, по сути, отличается сетевое приложение от обычного настольного приложения? Ничем!!! Есть, только, удалённый источник данных и необходимость ожидания ответа. Сколько же трудностей породило на заре Интеренета обманчивая простота писать HTML-странички. И понеслось…
И… что это за точки в тексте запроса: Я немного отстал от жизни и мне требуется пояснить синтаксис.
На первый взгляд, всё выглядит понятным. На это и рассчитано.
Насколько я помню, это традиционно для Си возвращать именно такие значения, чтобы в месте вызова можно было бы реализовать обработку для случая произошедших изменений. Было бы логичнее иметь в качестве кода возврата
bool, но это же Си! (NB: надо свериться с последним стандартом!)Далее, название функции:
CheckModemConnection. А если придётся проверять ещё чего-нибудь, то надо будет писать отдельную функцию для вот этого самого чего-нибудь? Мне бы ужасно захотелось бы обобщить и иметь общую для всех функцию проверки. Даже, если в Си нет классов. (Всегда можно ввести.) К тому же, для того, чтобы иметь возможность проверять состояние, неплохо бы как-то формализовать сие понятие и сделать так, чтобы, например, пробегать по списку необходимых свойств в цикле, а не создавать длинное условие для оператораif.В конце-концов, было бы крайне любопытно (и эффективно?) иметь текстовую строку, описывающую текущее состояние объекта, каждый символ которой связан с некоторым элементом описания модемного соединения. Делая простой проход по этой строке, можно было бы сразу получать ответ на нужный вопрос. А, если само символьное представление делать более сложным (XML?), то можно было бы автоматизировать выдачу диагностических сообщений (например, соединяя друг с другом строки состояния для различных элементов в единую строку).
Буду считать это хорошим напутствием.
В основе всего всегда лежат какие-то идеи. Бывает, и довольно глубокие. Но! В действительности, реализуется далеко не всё и не так, как это должно и могло бы быть на самом деле. По сути, новая технология только после нескольких этапов своего развития доходит до того, что реализует некое подобие задуманного в самом начале. Вот, я и задумался над тем, что же это могло бы быть, если бы многие вещи, которые нам сейчас знакомы, были бы реализованы в самом начале и стали бы органической частью Интернета.
В таком случае, задам вопрос Вам. Если это так есть (а я это и предполагал, когда писал статью), то зачем понадобились WEB-странички?
Вот я и спрашиваю, что именно сложилось и как это получилось.
Есть ли Вас собственная версия событий (почему именно так, и что было виною)?
Да и, вообще, все эти «холивары» изначально лишены всякого смысла. Хороший программист напишет хорошую программу на том языке, который он знает. Какой знает, так и знает. Но, уж, если знает, то знает хорошо. Плохой программист не знает ни одного языка и, соответственно, ни на одном языке не сможет ничего путного написать.
Так что, на этом, попрошу всякий «холивар» на Хабрахабре прекратить. Спасибо за понимание. ;-)
И… не надо никому желать гореть в адском пламени.
Все там будем.(в сторону) Интересно, а как можно нарисовать точный квадрат? Ведь, его надо будет рисовать прямоугольником. Там нужно использовать коэффициент искажения (aspect ratio?)…
Об этом и речь! Это и есть проблема.
1. Да, есть SOAP, XML-RPC, JSON REST и т.д. и т.п. Но вопрос не в том, что есть, а в том, что могло бы быть. На этот вопрос Вы не ответили.
2. CORBA была мною упомянута исключительно как пример технологии, которая, может быть, где-то сейчас и используется, но, в своё время, эта технология претендовала на очень многое. И, если бы, CORBA (или её более продвинутый аналог) хорошо развивалась, то, вполне возможно, SOAP, XML-RPC, JSON REST просто не появились бы по той простой причине, что все их функции были бы изначально встроены в единую технологию, и не надо было бы «городить огород». Но, это всё — не более чем предположение.
3. За безопасность локального приложения отвечает операционная система (ОС), и, по идее, именно ОС должна обеспечивать приложению что-то вроде «песочницы». А если само создание ОС будет нам гарантировать отсутствие вредоносного кода? Откуда, кстати, он появляется? Передаётся по сети? А зачем код передавать по сети? Всё должно быть и так уже установлено в ОС. Чего может не хватать распределённому приложению? Реализации каких-то специфических функций. Хорошо. Можно загрузить их с сайта, с которым Вы работаете. Но это должна быть рядовая операция установки программного обеспечения (ПО). Но, опять же, это всё — некое предположение о том, что «мир мог быть другим».
4. Если мы живём в мире, где WEB-приложений нет, то все приложения — локальные. Следовательно, все процессы обслуживаются рядовым ПО, то есть, самой ОС. Заметьте, единообразно! Стороннему приложению нужно, только задать обработчик. Но если документ, с которым Вы работаете, реализуется объектной моделью самой ОС, то внешнему сайту достаточно передать Вашей ОС карту переходов (от одних документов к другим).
5. И, наконец, самый тяжёлый вопрос: а зачем нам браузер? Большая часть содержимого Интернета хорошо укладывается в формат базы данных, и для просмотра этого содержимого вполне достаточно стандартных визуальных компонентов ОС. Зачем Вам заходить в браузере на нужный Вам сайт со списком, там, «чего-нибудь» (новостей, статей, обсуждений, товаров, книг), если Вы должны зайти у себя в ОС в приложение «База данных», где Вам будет достаточно подключиться к соответствующему узлу и получить от него требуемый Вам набор данных? Зачем нам страничный доступ к Ютьюбу, если у нас есть свой плеер (который всегда работает!), и нам нужно, только, иметь ссылку на источник потока?
Об этом и речь! Строго говоря, должен быть только один браузер, реализованный в самой ОС: с единой документной моделью и гарантирующим всем приложениям единообразное поведение.
Почему нужно всё только усложнять, а не упрощать? Разве грамотное применение информационных технологий не заключается в создании простых и прозрачных схем взаимодействия?
Сама же обсуждаемая здесь статья довольно любопытна. Спасибо за перевод. Но, разве, есть что-то предосудительное в том, чтобы пытаться представить себе другой мир, в котором таких проблем (вроде описываемых в статье) попросту нет, поскольку «мир другой», и в этом «другом мире» совершенно другая архитектура построения приложений?
Чем, по сути, отличается сетевое приложение от обычного настольного приложения? Ничем!!! Есть, только, удалённый источник данных и необходимость ожидания ответа. Сколько же трудностей породило на заре Интеренета обманчивая простота писать HTML-странички. И понеслось…
Web-тройка, куда несёшься ты? Не даёт ответа…