По вашему вопросу: «что происходит после использования use» (хотя это и не подпадает под тематику статьи)?
Говоря в начале файла «use foo:: bar:: Baz as FooBarBaz;» — мы даем понять интерпретатору, что если при компиляции в данном файле будет обращение к классу FooBarBaz (создание экземпляра, обращение к статическому методу или свойству) — то это означает, что следует использовать при этом класс Baz из пространства имен foo:: bar. При этом в другом файле мы можем написать use anotherfoo:: bar:: Baz as FooBarBaz; — use имеет эффект до конца файла.
По вашему замечанию «Если это просто зависимости может проще их обозначать через doc блоки? А если не только, то зачем?»
doc блоки хороши, но программисты, к сожалению, не так хороши. Заставить программиста писать комментарии — зачастую непростая задача. С неймспейсами вам фактически придется указывать каждую зависимость (уж по крайней мере, если она не находится в том же пространстве имен, что и класс, который вы пишете) — это необязательно, но так писать будет гораздо удобнее, и вот появится блок вроде такого:
namespace my;
use anotherns::foo;
use foo::Class1;
use foo::Class2;
class Something {
function bar(Class1 $c){...}
}
Кроме того, сама ситуация, в которой окажется программист, будет его дисциплинировать (а по рукам его бить надо, ага ;)): если вдруг он забудет указать «use foo::Class1;» и объявит метод как function bar(Class1 $c) {...} — то интерпретатор посчитает, что метод bar() должен принимать на вход объект my::Class1 — и ругнется при попытке передать ему экземпляр foo::Class1.
Пожалуй, надо было отметить, что топик будет интересен лишь тем, кто уже знаком с php-5.3 и его концепцией namespace'ов… Впрочем, я готов обсудить любые моменты по этой теме, которые кажутся непонятными или нераскрытыми в топике. А вот размытыми фразами вроде «тема не раскрыта», к сожалению, не помочь ни себе, ни другим :)
function smarty_block_block($params, $content, Smarty $smarty) — здесь имеется неточность: type-hinting нужно указывать как mySmarty $smarty — ведь в оригинальном Smarty нет методов set/getBlock.
А еще пробки от пивных бутылок собирали и играли на них. Делали самострелы, бьющие какими-то железными стрелами, рогатки из проволоки с проволочными же пульками. А еще модели пластмассовые клеили — корабли там, самолеты… А тетрисы и стикерсы, по-моему, несколько позже были, но могу и ошибаться. Просто как-то не припомню таких иностранных слов в своем детстве.
О Великий! Вы снизошли до моего уровня и продолжили!
К вашему сведению, на определенных уровнях нагрузки проекту абсолютно нет дела до того, кто там в нем отдает видео-контент :) В моем случае решение на PHP было очевидно самым простым.
Если бы вы потрудились прочитать статью о видео, ссылку на которую я привел в этом посте, вы бы знали, что мне известно о других способах «отдачи» видео.
Но вот вы говорите очевидную чушь: «Они (способы) просто ОБЯЗАНЫ быть реализованными без PHP в связке с сессиями». Это, скажите, перед кем обязаны? Чем вам PHP не угодил, если он прекрасно справляется со своей задачей? Чем вам сессии не нравятся? Если в проекте используются PHP-сессии — очевидно, что и для проверки прав доступа к видео-контенту удобнее всего использовать эти самые сессии.
Никаких «известных проектов, в которых используется PHP для отдачи видео», само собой, нет и быть не может. Но не забывайте о других проектах, с посещаемостью не миллионы, скажем, а всего лишь пару-тройку сотен тысяч хитов и меньше: представьте себе, там тоже иногда нужно видео! И вот незадача — PHP здесь великолепно справится и усом не поведет!
Вдобавок, вернусь к своему предыдущему комментарию и не поленюсь процитировать:
«вы просто «не въехали» в тему. В данном топике конкретная задача, которую выполняет скрипт — вообще не должна интересовать читателя, я написал про выдачу видео — просто чтобы дать реальный пример (и, да, в моем конкретно случае мы дествительно работали с видео). С тем же успехом можно было бы отправлять какие-то SOAP-запросы по сети, в общем, подойдет любое действие, которое требует существенных временных затрат»
Помимо прочего, вы просто «не въехали» в тему. В данном топике конкретная задача, которую выполняет скрипт — вообще не должна интересовать читателя, я написал про выдачу видео — просто чтобы дать реальный пример (и, да, в моем конкретно случае мы дествительно работали с видео). С тем же успехом можно было бы отправлять какие-то SOAP-запросы по сети, в общем, подойдет любое действие, которое требует существенных временных затрат.
Ого. Оказывается, вы знаете лучше меня и тех, кто ставит мне задачи, — что должна, а что не должна делать реализация отдачи видео?
Интересно, интересно… Я уже говорил, однако, что «на сайте использовалась авторизация»… Так вот, по условиям задачи, авторизованные пользователи могут смотреть видео, а неавторизованные — не могут (умолчим про то, что авторизованные, допустим, могут смотреть одно видео и не могут смотреть другое). Итак, берем слова про сессию назад?
А я, заметьте, не просил обучать меня «программированию и проектированию». Тем более мне не нужно такое обучение от человека, который даже в элементарном вопросе не может сколько-нибудь осмысленно обосновать свою позицию. Я не вижу связи ваших комментариев с моим постом. Потрудитесь высказать свою точку зрения более подробно:
1. Что вам не понравилось в реализации отдачи видео? (кстати, в посте ее, родимой, — реализации-то — нетути. Вы ктулху и сейчас едите мой мозг? )
2. Из чего вы заключаете, что «про сессии Вы, наверное, вообще не вкурсе, для чего они используются»?
3. Каким боком вы планируете увязать с моим постом фразу про сэйв-хэндлеры?
Беспроводная сеть под названием «Прекратите красть мой интернет!» — напомнило мне, как в этом году на линуксфесте я оставил безо всякой охраны примерно на часа два — три ящика пива, только написал на бумажке и положил ее сверху: «Пожалуйста, не берите это пиво, возьмите какое-нибудь другое».
(пиво дождалось своих хозяев в целости и сохранности)
Доделают или не доделают — речь совсем не о том. Главное — что фактически без ведома пользователя (в данном случае, PHP-разработчика) стандартные функции подменяются функциями расширения. Это, по понятным причинам «не добавляет» производительности, да еще добавляет потенциальных багов. Лично мне гораздо спокойнее, когда я уверен, что при вызове is_file() или другой стандартной функции из «ядра» — вызовется именно эта функция, а не из какого-то расширения.
Что-то я не нахожу ни капли полезного смысла в ваших комментариях. Если вы все это знаете или можете логически/экспериментально вывести все, что нужно — этот топик просто не для вас. Он как раз для тех, кто, столкнувшись с подобной ситуацией, будет долго чесать репу и искать решение. И вообще, честно говоря, не понимаю, почему лично вы (если все, что здесь изложено, вам хорошо знакомо и, следовательно, неинтересно) — так оживленно комментируете :)
Описано-то оно описано… Вот только — где описано? На странице документации к session_write_close. Я вас уверяю, далеко не каждый (к сожалению) программист читает доку на каждую используемую функцию. В частности, человек, о котором я упомянул («товарищ пожаловался на точно такую же проблему») — довольно опытный PHP-программист, и его данная ситуация поставила в тупик, впрочем, как и меня поначалу. В мануале приведен пример с фреймсетами, у меня пример немного другой, но главное: я хотел описать симптомы неполадки и рецепт для их решения, чтобы некоторые люди подобные проблемы решили быстро — когда с ними столкнутся.
Берем фильм. Берем его мета-данные (позиции ключевых фреймов). Выбираем время начала трансляции. Пришел запрос: смотрим разницу по времени — время запроса минус время начала трансляции. Вычитаем кол-во целых фильмов, которые бы поместились на этом отрезке. Допустим, весь фильм = час. Запрос пришел через полтора часа после выбранного времени начала трансляции. Отбросили час (продолжительность фильма), осталось полчаса. «Проматываем» на полчаса вперед и показываем.
Можно нечто подобное с несколькими фильмами сделать, в случайном порядке их показывать. Клиент может в промежутках между фильмами показывать пользователю заставки, рекламу и т. д.
нет, проблема динамического ЦСС не в этом. Заголовки, отвечающие за кэширование, PHP или любой другой язык можно отдать без проблем.
Мое мнение: проблема такого подхода в его нестандартности (а покажите мне стандарт/спецификацию такой записи, да чтобы разработчики его знали) — это раз; лишние нагрузки на сервер — два; Заголовок User-Agent (а как еще вы собираетесь на сервере определить, каким браузером пользуется клиент) — так вот, заголовок User-Agent не является обязательным, может «зарезаться» прокси-сервером, может вообще содержать любую чушь или недостоверные данные (в опере раньше прям на виду был дропдаун-бокс «Identify As Opera/MSIE/Firefox») — это три. Это так — то, что вот прямо сейчас пришло в голову.
1. Стрим — весьма условная защита от копирования.
2. Такими вопросами я не занимался, но есть предположение (пока что я не смотрел в доке), что Red5 может это уметь.
Вопрос: лучше на отдельный сервер или же на сервер с работающим порталом? Ответ: при небольших нагрузках нет разницы, а следовательно, зачем платить больше? (за отдельный сервер).
Если все же необходим стрим — посмотри сначала в сторону Red5. Если не устроит — смотри флэш-медиа-сервер. Кстати, с помощью HTTP-download можно организовать простую защиту контента (только от дурака, в общем-то, но стрим, по большому счету, тоже не предоставляет бОльшей защиты). При этом медиа-сервер вообще необязательно ставить. Задача с псевдо-ТВ-каналом тоже решаема при помощи любого языка программирования (при небольших нагрузках тот же PHP или любой другой скриптовый язык справится).
По вашему вопросу: «что происходит после использования use» (хотя это и не подпадает под тематику статьи)?
Говоря в начале файла «use foo:: bar:: Baz as FooBarBaz;» — мы даем понять интерпретатору, что если при компиляции в данном файле будет обращение к классу FooBarBaz (создание экземпляра, обращение к статическому методу или свойству) — то это означает, что следует использовать при этом класс Baz из пространства имен foo:: bar. При этом в другом файле мы можем написать use anotherfoo:: bar:: Baz as FooBarBaz; — use имеет эффект до конца файла.
По вашему замечанию «Если это просто зависимости может проще их обозначать через doc блоки? А если не только, то зачем?»
doc блоки хороши, но программисты, к сожалению, не так хороши. Заставить программиста писать комментарии — зачастую непростая задача. С неймспейсами вам фактически придется указывать каждую зависимость (уж по крайней мере, если она не находится в том же пространстве имен, что и класс, который вы пишете) — это необязательно, но так писать будет гораздо удобнее, и вот появится блок вроде такого:
namespace my; use anotherns::foo; use foo::Class1; use foo::Class2; class Something { function bar(Class1 $c){...} }Кроме того, сама ситуация, в которой окажется программист, будет его дисциплинировать (а по рукам его бить надо, ага ;)): если вдруг он забудет указать «use foo::Class1;» и объявит метод как
function bar(Class1 $c) {...}— то интерпретатор посчитает, что метод bar() должен принимать на вход объект my::Class1 — и ругнется при попытке передать ему экземпляр foo::Class1.Надеюсь, ситуация хоть немного стала яснее.
К вашему сведению, на определенных уровнях нагрузки проекту абсолютно нет дела до того, кто там в нем отдает видео-контент :) В моем случае решение на PHP было очевидно самым простым.
Если бы вы потрудились прочитать статью о видео, ссылку на которую я привел в этом посте, вы бы знали, что мне известно о других способах «отдачи» видео.
Но вот вы говорите очевидную чушь: «Они (способы) просто ОБЯЗАНЫ быть реализованными без PHP в связке с сессиями». Это, скажите, перед кем обязаны? Чем вам PHP не угодил, если он прекрасно справляется со своей задачей? Чем вам сессии не нравятся? Если в проекте используются PHP-сессии — очевидно, что и для проверки прав доступа к видео-контенту удобнее всего использовать эти самые сессии.
Никаких «известных проектов, в которых используется PHP для отдачи видео», само собой, нет и быть не может. Но не забывайте о других проектах, с посещаемостью не миллионы, скажем, а всего лишь пару-тройку сотен тысяч хитов и меньше: представьте себе, там тоже иногда нужно видео! И вот незадача — PHP здесь великолепно справится и усом не поведет!
Вдобавок, вернусь к своему предыдущему комментарию и не поленюсь процитировать:
«вы просто «не въехали» в тему. В данном топике конкретная задача, которую выполняет скрипт — вообще не должна интересовать читателя, я написал про выдачу видео — просто чтобы дать реальный пример (и, да, в моем конкретно случае мы дествительно работали с видео). С тем же успехом можно было бы отправлять какие-то SOAP-запросы по сети, в общем, подойдет любое действие, которое требует существенных временных затрат»
Интересно, интересно… Я уже говорил, однако, что «на сайте использовалась авторизация»… Так вот, по условиям задачи, авторизованные пользователи могут смотреть видео, а неавторизованные — не могут (умолчим про то, что авторизованные, допустим, могут смотреть одно видео и не могут смотреть другое). Итак, берем слова про сессию назад?
И кстати, где ответы на 2-й и третий вопросы?
1. Что вам не понравилось в реализации отдачи видео? (кстати, в посте ее, родимой, — реализации-то — нетути. Вы ктулху и сейчас едите мой мозг? )
2. Из чего вы заключаете, что «про сессии Вы, наверное, вообще не вкурсе, для чего они используются»?
3. Каким боком вы планируете увязать с моим постом фразу про сэйв-хэндлеры?
(пиво дождалось своих хозяев в целости и сохранности)
Ничего не скажу. Не пользуюсь платным софтом :)
Берем фильм. Берем его мета-данные (позиции ключевых фреймов). Выбираем время начала трансляции. Пришел запрос: смотрим разницу по времени — время запроса минус время начала трансляции. Вычитаем кол-во целых фильмов, которые бы поместились на этом отрезке. Допустим, весь фильм = час. Запрос пришел через полтора часа после выбранного времени начала трансляции. Отбросили час (продолжительность фильма), осталось полчаса. «Проматываем» на полчаса вперед и показываем.
Можно нечто подобное с несколькими фильмами сделать, в случайном порядке их показывать. Клиент может в промежутках между фильмами показывать пользователю заставки, рекламу и т. д.
Мое мнение: проблема такого подхода в его нестандартности (а покажите мне стандарт/спецификацию такой записи, да чтобы разработчики его знали) — это раз; лишние нагрузки на сервер — два; Заголовок User-Agent (а как еще вы собираетесь на сервере определить, каким браузером пользуется клиент) — так вот, заголовок User-Agent не является обязательным, может «зарезаться» прокси-сервером, может вообще содержать любую чушь или недостоверные данные (в опере раньше прям на виду был дропдаун-бокс «Identify As Opera/MSIE/Firefox») — это три. Это так — то, что вот прямо сейчас пришло в голову.
Верстайте без хаков. Аминь.
2. Такими вопросами я не занимался, но есть предположение (пока что я не смотрел в доке), что Red5 может это уметь.
Вопрос: лучше на отдельный сервер или же на сервер с работающим порталом?
Ответ: при небольших нагрузках нет разницы, а следовательно, зачем платить больше? (за отдельный сервер).
Если все же необходим стрим — посмотри сначала в сторону Red5. Если не устроит — смотри флэш-медиа-сервер. Кстати, с помощью HTTP-download можно организовать простую защиту контента (только от дурака, в общем-то, но стрим, по большому счету, тоже не предоставляет бОльшей защиты). При этом медиа-сервер вообще необязательно ставить. Задача с псевдо-ТВ-каналом тоже решаема при помощи любого языка программирования (при небольших нагрузках тот же PHP или любой другой скриптовый язык справится).