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

Ну да ладно, оставим это на их совести. А сейчас поговорим лучше о правильных ссылках.

1. Во-первых, нужно делать ссылки информационно-значимыми. Например, что значит ссылка "ЗДЕСЬ"? Только не надо говорить, что она хорошо смотрится вместе с текстом. Нет, она и с текстом смотрится отвратительно.

2. Ссылка должна быть удобной для чтения. Чтобы ссылка была удобной, она должна состоять не более чем из четырех слов. Ни в коем случае нельзя допускать на своем сайте то, что сделано на сайте utro.ru (практически кажды кусок текста - ссылка) - в такой ситуации пользователям очень неудобно ориентироваться на сайте, можно попасть мышкой не туда, куда нужно.

3. Ссылка должна быть подчеркнутой (это нельзя считать постоянным правилом, но делать ссылки неподчеркнутыми можно только в 25% случаев). Дело в том, что пользователи привыкли к тому, что ссылки подчеркнутые. Просто привыкли. И отвыкать не хотят. К тому же подчеркнутые ссылки хорошо выделяются среди остального текста.

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

Сведем теперь преимущества Fast CGI воедино. Производительность Fast CGI существенно выше, чем у CGI, и немногим уступает API. Существуют даже примеры, когда Fast CGI работает быстрее API-приложения. Мигрировать от CGI к Fast CGI гораздо проще, чем к API. Кроме того, Fast CGI можно использовать и просто как обычный CGI.

Спецификация доступна для широкого спектра как коммерческих, так и свободно распространяемых серверов, что делает скрипты мобильными. Кроме того, FCGI позволяет организовать распределенные вычисления, то есть работать с удаленными информационными ресурсами самостоятельно без сервера, установленного на вычислительной установке, на которой исполняется скрипт.
Некоторые итоги

Выше мы перечислили основные способы расширения возможностей сервера протокола HTTP, которые имеются у разработчика Web-узлов.

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

Другое дело - распределенная информационная система. Здесь, имея в виду "зоопарк" аппаратных и программных возможностей, придется решать много задач, которые не встают обычно перед администрацией Website. Но где появляются эти системы? Ответ на самом деле один: в системах intranet.

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

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