Как заставить OPERу грузить .PHP файлы не из кэша, а с сервера?

[IF]

Как заставить OPERу грузить .PHP файлы не из кэша, а с сервера?

Вставлять в URL ?<строка>
Как отнесутся поисковики - как к сознательному увеличению страниц на сайте, как к спаму?
А по другому не знаю как обмануть это чудо.

-~{}~ 21.02.07 16:10:

ЗЫ Попробую послать заголовки, для запрета кэширования. Может поможет?

 

[ktulhu]

Re: Как заставить OPERу грузить .PHP файлы не из кэша, а с сервера?

ЗЫ Попробую послать заголовки, для запрета кэширования. Может поможет?

Как раз наоборот. Стоит установить кэширование в течение года - это позволит поисковику держать ваши страницы в памяти. Страницы с no-cache не индексируются самыми популярными посиковиками. Страницы с кэшем установленным в течение дня, храняться в поисковиках неделю.
Дольше всего в поисковиках храняться статичные страницы.
Есть параметр в php.ini, позволяющий скрыть футпринт php, таким образом поисковики не узнают, что ваши страницы генеряться динамически. Я вообще вам рекомендую выдавать страницы не в поток, а рендерить их в файловую систему. Таким образом, вы избавитесь от неуклюжих гет-параметров и получите сверхбыстрый отклик сервера (не нужно будет тратить время на запуск интерпретатора). Структуру директорий рекомендую разбить логически, например, [ваш_сайт]/blog/post/23 (это значит файл "23" в директории blog/post относительно document root).
Опера такие проблемы решает мгновенно и, более того, подсасывает всю структуру директорий, что эквивалентно прелоадеру во флэш-файлах. К сожалению, IE не поддерживает данный вид прелоадера.

 

[Sluggard]

Есть догадка, что где-то в настройках Оперы есть опция, позволяющая отключить плугин PHP. Попробуй поискать. Тогда опера посмотрит, что не может выполнить php-скрипт и позволит это выполнять серверу. Хмм... Хотя возможно, что тогда Опера начнет переправлять серваку закешированные php-скрипты, чтобы тот их выполнил, и выдал выполненный php-скрипт. Вероятно, там должна быть еще одна опция "Оптимизировать процесс". Если ее установить, Опера не станет слать те скрипты php, которые уже есть на сервере. Ей останется только проверять есть ли такой-то скрипт, или надо его прислать. В общем искать надо в настройках где-то.

 

[ktulhu]

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

Коллега, я с вами не согласен. Опера отсылает на сервер байт-код, что есть само по себе резкое увеличение производильности и разгрузки канала до сервера. Поскольку Опера поддерживает JS, значит можно оптимизировать процесс и отсылать только часть байт кода, приведя страницы в соответствии с парадигмой Web 2.0.

-~{}~ 21.02.07 20:46:

Возможно, вас заинтересует тема объема записи инорфмации в <div>ы. Это очень перспективное направление, тем более, что современные поисковые сервисы резко подымают ваши шансы попасть в top10, ввиду того, что ваш сайт написан с помощью <div>ов и стандартов W3C.
По поводу ограничения объема информации в <div>ах, прочитайте соседний топик http://phpclub.ru/talk/showthread.php?s=&threadid=96728&rand=20.

 

[Sluggard]

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

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

 

[ktulhu]

Автор оригинала: Sluggard
Возможно он кеширует байт код также - Вы правы Но он обязан кешировать и не только байт-код на тот случай, если яваскрипт отключен в браузере.

В таком случае лучше воспользоваться cookie и хранить скомпилированный байт-код яваскрипта там. Более того, группам сайтов одного владельца это весьма полезно, ибо в cookie можно хранить часто используемый код: скорость считывания браузером из cookie невероятно высока, тем более что на ряде сайтов и сервисов используются одни и те же функции; cookie в таком случае являются репозиторием Часто Используемого Кода (ЧИК). Есть даже cookie-фреймворки с бэк-эндом на php, предоставляющие функционал аналогичный системам cvs.

 

[Sluggard]

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

С этим не могу согласиться. Получится, что сайт не будет индексироваться в течении года?

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

Я вообще вам рекомендую выдавать страницы не в поток, а рендерить их в файловую систему.

Противоречие однако

Структуру директорий рекомендую разбить логически, например, [ваш_сайт]/blog/post/23

А как сервер узнает, что в /blog/post/ не находится файл, который генерируется в соответствии с данными, переданными формой методом post? В таком случае либо пользователю будут подсовываться старрые данные, либо ни о какой экономии ресурсов при запуске интерпритатора не может идти и речи!

 

[asm]

Ок попробую поучавствовать:
Лучше всего сразу писать в байткоде и забить на поисковики.
Соррри, просто хорошее настроение.!

 

[Фанат]

ktulhu
Спасибо за интересную идею.
я думаю, что систему хранения ЧИК можно толковать шире, и в таком варианте она отправит модный AJAX на свалку истории. Зачем обращаться к серверу, если можно обращаться к кукам, если, как правильно было замечено, скорость чтения информации из кук очень высока.

однако, в этой теме это оффтопик.
по сути вопроса я бы осоветовал автору решение, которое одним выстрелом убьёт двух зайцев: разместить кэш Оперы на сервере! Таким образом, откуда бы она ни брала файлы - они всё равно будут с сервера.
Насколько мне известно, это единственный способ заставить работать этот маргинальный браузер так, как это нужно программисту.

 

[asm]

Фанат
Я конечно тоже недолюбливаю Оpera но р\назвать его маргинальным это смело Покраней мере никто не обьявлял "ЭПОХУ" Opera оконченой.

 

[dimagolov]

2 asm, Sluggard, ktulhu
пацаны, а где вы такую траву берете? мне тут до Ямайки совсем близко, но такой травы нигде не встречал

P.S. "ЭПОХА" Opera это в цитатнег, без вариантов

 

[ktulhu]

Автор оригинала: Фанат
ktulhu
Спасибо за интересную идею.
я думаю, что систему хранения ЧИК можно толковать шире, и в таком варианте она отправит модный AJAX на свалку истории. Зачем обращаться к серверу, если можно обращаться к кукам, если, как правильно было замечено, скорость чтения информации из кук очень высока.

Тут некоторые считают, что я глумлюсь и курю нечто зелененькое с острыми зубчиками, однако, зайдите сюда
http://www.rus-shopping.com/index.php

Данный сервис предоствляет возможность оценки домена (в денежном эквиваление) по определенным критериям. Но это не суть интересно! Замечательно другое: попробуйте оценить несколько доменов подряд и вы увидите, что капча (или код, кому как нравится) ВСЕГДА одинаковая, однако изображение КАЖДЫЙ РАЗ перерисовывается и оно КАЖДЫЙ РАЗ новое.

Доподлинно известно, что владельцы сайта используют wrapper для cookie для построения captcha. Что это значит? Что cookie являются отличным инструментом для работы в среде веб.

Единственное ограничение по captcha - ни javascript ни cookie не умеют генерировать изображения. Создатели вышеуказанного сайта решили перенести функционал по отрисовке изображения на серверную часть, все остальное храниться в cookie!

Но заметьте - остальной код храниться в cookie, также как и данные по captcha.

 

[boombick]

Вот это трава!! Отсыпьте, парни!!!

 

[ktulhu]

И еще: заметьте, насколько сильно выросла роль клиентских технологий. Буквально несколько лет назад все зависели от серверных решений и были жестко ограничены набором серверных технологий, которые в основном выдавали html-код в поток. Пользователь никак не мог повлиять на ход событий...

И смотрите, что происходит сегодня!
Более того, помяните мое слово - скоро серверы будут выполнять лишь роль трекеров (bittorrent) и связвать пользователей сайта друг с другом по замечательной технологии peer-2-peer. А хранилищем данных для такого распределенного решения будут cookie. Единственная проблема, которая, я надеюсь, решиться в ближайшие 10 лет - это именно трекер для связывания всех пользователей сайта.

Для этого у меня есть идея. Необходимы cookie-injection (возможно RPC-cookie) для того, чтобы функционал сайта делить между пользователями.

Вы только представьте себе, что, например, вы хотите поиск от гугла прикрутить к любимому форму (например, phpclub.ru). И все что нужно будет - это простая cookie-injection. Данные ведь все равно находятся у участников и вы знаете этих участников (через трекер). Небольшой байт-код от гугла - и у вас поиск по форуму под рукой. А ведь так можно любой функционал с любого сайта совмещать!

Есть правда одна проблема, которую я вижу - это необходимость создания алгоритма интеллектуального распределения данных сайта между конечными точками. Например, конкретного ваши посты должны лежать у вас в cookie - и выдавать по запросу других peer'ов.

Тема перспективная и прибыльная, поверьте мне.

 

[dimagolov]

Автор оригинала: ktulhu
Тема перспективная и прибыльная, поверьте мне.

ИМХО тема плавно перетекает из фармакологической в медицинскую, хотя она была там изначально

 

[ktulhu]

Автор оригинала: dimagolov
ИМХО тема плавно перетекает из фармакологической в медицинскую, хотя она была там изначально

Это, простите, оффтопик. Лучше бы подсказали алгоритм определения двух самых надеждных peer'ов для конкретного user'а, чтобы учитывались и скорость соединения, и т.п.

Как например, оценить семантическую топологию треугольника (выбрать три вершины (peer'а) наиболее близких друг другу) с учетом персональных, профессиональных интересов, а также схожести лексико-коммуникативных установок?

 

[Фанат]

ktulhu
позволю себе не согласиться.
Я считаю, что достоинства технологии peer-2-peer вообще и
bittorrent в частности - сильно преувеличены, а популярность - раздута. при том, что пользуются ей в итоге единицы.
Есть более надежные и проверенные временем решения. Например - email. Все популярные браузеры имеют в своем составе еmail-клиент, а практически все пользователи интернета имеют адрес электронной почты. то есть, доступность технологии гораздо выше. Но это не главное. Есть одна небольшая проблемка, которая ставит крест на использовании cookie - а именно предельный размер базы, который, если мне не изменяет память равен 20 килобайтам. при том, что объём почтовой базы не ограничен ничем!

Поэтому, придерживаясь в общих чертах предложенной технологии, я склонен вместо cookie и peer-2-peer использовать электронную почту.
причем вся система упрощается в разы! Берём пример с гуглем. Браузер всего лишь посылает письмо в гугль, который, с помощью мощнейшей системы Google Mail отправляет в браузер серию писем с результатами поиска. Вуаля!
Между прочим, наличие у всех, поголовно, поисковых систем собственной веб-почты является неопровержимым доказательством того, что в скором времени нас ждёт переход на протокол HER://(Hypertext Email Retransmission), как замену устаревшему HTTP.

 

[ktulhu]

Автор оригинала: Фанат
ktulhu
а именно предельный размер базы, который, если мне не изменяет память равен 20 килобайтам. при том, что объём почтовой базы ничем не ограничен!

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

Берём пример с гуглем. Браузер всего лишь посылает письмо в гугль, который, с помощью мощнейшей системы Google Mail отправляет в браузер серию писем с результатами поиска. Вуаля!

Совсем не вуаля. Опять начинаются привязки к серверу (в данном случае к мэйл-серверу), а это - смерть.
Есть правда интересное решение: хранить БД в мэйл-клиенте и через COM обращаться к каждому письму, в котором лежит часть БД в формате куки. Т.е., таким образом мы будем иметь коллекцию объектов БД с данными. Переключение между объектами коллекции может происходить посредством подмены указателя.

Между прочим, наличие у всех, поголовно, поисковых систем собственной веб-почты является неопровержимым доказательством того, что в скором времени нас ждёт переход на протокол HER://
(Hypertext Email Retransmission), как замену устаревшему HTTP.

Я бы добавил еще две буквы для уточнения термина
NAHER - Non Ambiguous Hypertext Email Retransmission - что будет резко выделять концепцию среди недореализованных и полуумерших stateless протоколов типа http.

 

[bgm]

Если джентельмену нечего сказать - он предпочтёт промолчать... Вау...

 

[Фанат]

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

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

Опять начинаются привязки к серверу (в данном случае к мэйл-серверу), а это - смерть.

Но использование мобильных устройств и беспроводных технологий дает нам ещё одно преимущество - отсутствие зависимости не только от централизованных серверов, но и от наземных каналов связи! С их СОРМ-ами, Echelon-ами и прочими системами тотальной слежки.
мобильные устройства связываются друг с другом по протоколу Bluetooth, у каждого в памяти хранится автоматически обновляемая иерархическая таблица роутинга. Роутинг организуется по принципу территориальных сетей. Во главе каждой сети стоит так называемый NC, что расшифровывается, как "Not Connected".

При отправке запроса в гугль браузер клиента связывается с ближайшим беспроводным устройством, которое, сверяясь по таблице роутинга, передает запрос с помощью системы глобального позиционирования GPS в доступное мобильное устройство в Mountain View, California, которое и передает запрос напрямую у гугль и тем же путём возвращает назад!