Применение видео в сочетании с Flash технологией
Аннотация
нет
Введение
Традиционно, видео в Интернете представлялось скорее экзотикой, чем обычным явлением. Это было в первую очередь обусловлено ограничениями на скорость передачи информации, накладываемыми существующими линиями связи. В настоящее время благодаря развитию интернет-технологий значительно увеличилось количество, пользователей, обладающих скоростными линиями доступа к глобальной сети. В связи с этим видео стало достаточно часто использоваться в Сети как мощное средство рекламы и взаимодействия с аудиторией.
Возможные варианты интеграции видео при использовании Flash-технологии
Применение видео в сочетании с Flаsh - технологией имеет огромное преимущество, которое заключается в том, что видео воспроизводится в том же окне проигрывателя, что и Flаsh-фильм, и является неотделимым от него. Это позволяет очень тесно интегрировать видео в Web-среду, сделав его составляющим элементом SWF-документа. Flash МХ 2004 предоставляет три различных варианта интеграции видео в SWF-документ:
- внедрение видеофайла; динамическая загрузка видеофайла в формате FLV (Flash Video); потоковая загрузка и трансляция видео в формате FLV.
Внедрение видеофайла в состав SWF - документа
Возможность внедрения видеофайлов появилась еще в Flash 6. В результате внедрения видеофайла он становится частью SWF-документа. Характерной особенностью внедренного видео является жесткая при вязка к монтажной линейке. Внедренный видеофайл занимает диапазон кадров, длительность которого соответствует его продолжительности. Принципиально это очень похоже на использование анимированного символа типа Graphic. Основным преимуществом внедренного видео является возможность его тесной интеграции в среду Flаsh-документа. С внедренным видео можно работать, используя инструментарий векторного редактора и монтажной линейки. Можно выполнять операции масштабирования, поворота, скоса, использовать эффекты масок и даже анимацию. Поскольку внедренное видео привязано к монтажной линейке, можно очень легко создавать элементы управления его воспроизведением. Видео можно поместить на монтажную линейку клипа и управлять им, используя все возможности контроля клипов. Тем не менее у внедренного видео имеется ряд очень существенных недостатков:
- внедрение видео существенно сказывается на объеме конечного SWF-документа; При загрузке SWF-документа по сети внедренный видеофайл начинает воспроизводиться только после окончания своей загрузки; При воспроизведении SWF-документа внедренное видео должно быть полностью загружено в память компьютера пользователя; При воспроизведении внедренного видео в течение времени, превышающего 120 секунд, возможно нарушение синхронизации звука, и видео; Скорость воспроизведения внедренного видео всегда совпадает со скоростью воспроизведения, используемой в документе; Имеет место ограничение на длительность видео, которая не может превышать 16000 кадров; При необходимости обновления видео приходится редактировать содержащий его SWF-документ;
Динамическая загрузка видеофайла в формате Flash Video
С выходом Flash МХ 2004 у разработчиков появилась возможность осуществлять динамическую загрузку (progressive download) видео в формате FLV (Flash Video) в SWF-документ с помощью ActionScript. Для этого в SWF-документе создается контейнер, в который уже непосредственно в процессе воспроизведения документа загружается внешний FLV-файп. Программный инструментарий ActionScript позволяет осуществлять контроль состояния загрузки видеофайла, управление его воспроизведением и параметрами звука. К преимуществам динамической загрузки видео можно отнести следующие.
- Объем SWF-документа определяется только его содержимым и никак не зависит от объема видеофайла, который будет в него загружаться Воспроизведение динамически загружаемого видеофайла начинается, как только на диск будет записана порция информации, необходимая для начала воспроизведения Динамический загруженный FLV-файл загружается, кэшируется и затем воспроизводится с локального диска пользователя. Поэтому для запуска воспроизведения не требуется, чтобы весь видеофайл целиком был загружен в память компьютера Качество динамически загруженного видео выше, чем внедренного. Это объясняется тем, что кодек, осуществляющий импорт видео в Flash, обеспечивает более низкое качество по сравнению с кодеком, используемым при работе с динамически загруженным видео Отсутствуют проблемы синхронизации звука и видео Не существует ограничений на длительность видеофайла В видеофайле может использоваться скорость воспроизведения, отличная от скорости, используемой в Flаsh-документе
Потоковая загрузка и трансляция видео в формате Flash Video
Наряду с внедрением и динамической загрузкой видео Flash поддерживает возможности работы с потоковым Видео в формате FLV. Для этих целей в сочетании со средой разработки Flash используется самостоятельное приложение, которое называется Flash Соmmuniсаtion Server. При установке Flash Communication Server Мх в рабочей среде Flash МХ 2004 появляется набор дополнительных инструментов, включающих специальные инструкции Асtiоn Sсгiрt, служебные панели и компоненты, позволяющие осуществлять обмен потоковым Видео и аудио с сервером, поддерживающим Flash Соmmuniсаtion Server. При использовании этой технологии видео - и/или аудиопоток отправляется клиенту посредством соединения, установленного между его компьютером и видеосервером. При этом имеется возможность детального контроля характеристик соединения и потока данных, позволяющего достаточно гибко управлять параметрами видео, чтобы оптимальным образом приспособить его под текущую скорость соединения. Одним из преимуществ использования потокового видео и аудио является то, что поток данных, передаваемых с помощью Flash Соmmuniсаtion Server, воспроизводится на компьютере пользователя и сразу же удаляется из памяти, при этом кэширования данных не происходит. Flash Соmmuniсаtion Server позволяет обеспечить передачу потокового видео, записанного с помощью Web-камеры или DV-камеры, с одного компьютера одновременно нескольким другим пользователям. Это находит применение при создании видеоконференций в реальном времени или развлекательных порталов.
Сравнительные характеристики внедрения и динамической загрузки видео
Характеристика | Внедренное Видео | Динамическая загрузка видео |
Поддерживаемые форматы (Flash МХ 2004) | Audio Video Interleaved (АVI); | Flash Video (FLV) |
Кодирование | Кодируется при импорте в Flash с применением кодека Sorenson Spark; При импорте FLV перекодировка не требуется | Кодирование выполняется при экспорте из внешних приложений с применением плагина Flash Video Ехроrtеr; |
Размер файла | Видеофайл со звуковым сопровождением входит в состав SWF-документа, увеличивая его объем | Видео располагается отдельно от SWF-документа |
Привязка к монтажной линейке | Видеофайл жестко привязан к монтажной линейке и воспроизводится только на протяжении диапазона кадров, в которых он находится | Нет привязки к монтажной линейке |
Скоростью воспроизведения | Совпадает со скоростью воспроизведения, используемой в Flash-документе | Может отличаться от скорости воспроизведения, используемой в Flash-Документе |
Управление воспроизведением | Управление воспроизведением реализуется с помощью управления монтажной линейкой | Управление воспроизведением осуществляется с помощью класса NetStream |
Загрузка из Интернета | При воспроизведении SWF-документа внедренное видео должно быть полностью загружено в память компьютера пользователя для начала воспроизведения | для начала воспроизведения не требуется, чтобы весь видеофайл целиком был загружен в память компьютера |
Использование | Короткие видеофайлы небольшого размера с низкой скоростью воспроизведения | Более продолжительные видеофайлы большего размера с произвольной скоростью воспроизведения |
Совместимость | Flash Player 6 и выше | Flash Player 7 |
Заключение
абзацТаким образом благодаря мощному инструментарию среды разработки Flash приложений Macromedia Flash MX и особенностям формата Flash video созданы все предпосылки для более широкой интеграции видео в Web-среду, в частности для разработки полнофункциональной и динамической видеогалереи с возможностями просмотра и манипуляциями видео.
Литература
Flash и видео: импорт, экспорт и работа с SWF, FLV, MOV (QuickTime), AVI, MPEG; автор: Андрей Жебраков , , ActionScript 2.0 - СПб.:БХВ-Петербург, авторы: 2005 годЕдиное файловое пространство кафедры ЭВА
Аннотация (Annotation)
Статья посвящена проекту единого файлового пространства в рамках единой информационной среды кафедры ЭВА. Данный проект подразумевает создание единого места хранения всей пользовательской информации с предоставлением удобного и развитого интерфейса по управлению своими данными для всех пользователей кафедры.
This article is dedicated to the unified file storage system made as a part of unified information system of MSIEM EVA department. This project is meant to create a single space for storing any kind of users data that provides users with user-friendly and advanced interface for manipulating their data.
Общие сведения о ЕФП кафедры, его предназначение и этапы создания
Все пользователи единой информационной среды кафедры (запись о котором хранится в кафедральной LDAP) нуждаются в возможности хранения файлов и обмена ими. Для решения этой задачи был создан сервер share. *****.
Доступ к публикуемым файлам должен осуществляться различными способами, поскольку у каждого из которых есть свои преимущества и недостатки. Так, например, эффективность работы с файлами по HTTP технически ограничена неоправданными повышенными нагрузками на сервер при пересылки больших объемов информации, однако поддержка этого протокола позволяет сделать существенно более удобным интерфейс для пользователей и предоставляет бОльшую доступность сервера (т. к. для полноценной работы на клиентской стороне из установленного программного обеспечения требуется лишь наличие web-браузера).
Кроме того, необходимо создание гибкой системы прав на файлы для того, чтобы каждый мог публиковать на сервере файлы и только для личного использования, и для определенных либо для всех пользователей информационной системы кафедры, и для любых интернет-посетителей вообще. Это позволит:
- каждому пользователю ЕИС получить удобный сервис для хранения личных файлов, которые будут доступны только ему из любой точки мира, где есть подключение к глобальной сети Интернет; каждому пользователю ЕИС получить удобный сервис для публикации своих файлов, которые будут доступны всем пользователям глобальной сети Интернет; каждому пользователю ЕИС размещать в едином пространстве результаты различных учебных и исследовательских работ, доступ к которым будут иметь только определенные преподаватели, сотрудники кафедры и/или сокурсники и другие заданные группы пользователей; определенным пользователям ЕИС совместно работать над общими проектами.
Для развития возможностей совместной работы, а также расширения работы с некоторыми категорий файлов (это особенно актуально, в частности, для документов и исходного кода программных разработок) сервис со временем получит поддержку современной Open Source-системы контроля версий Subversion в связке с Apache и WebDAV.
Кроме того, для объединения всего файлового пространства кафедры вообще этот же сервер будет интегрирован с такими функционирующими службами кафедры, как Samba (для хранения в ЕФП личных настроек пользователей на кафедральных десктопах под управлением операционных систем GNU/Linux и Windows).
Таким образом, реализация единого файлового пространства кафедры состоит из следующих этапов:
Поэтапная реализация проекта на сервере
Этап 1. Первоначальная настройка сервера
Первой задачей после создания VPS для проекта стала интеграция системы с пользователями кафедры из LDAP.
Для этого для всех пользователей кафедры в LDAP были внесены небольшие поправки (с тем, чтобы каждый "узнавался" системой GNU/Linux). Список добавленных полей:
Кроме того, к полю objectClass было добавлено значение posixAccount, означающее, что данные из этого объекта LDAP могут использоваться совместимой со стандартом POSIX системой для авторизации.
В Gentoo Linux были установлены пакеты pam_ldap и nss_ldap:
# emerge pam_ldap nss_ldap
(Здесь и далее в статье указанный в начале команды символ "#" означает, что ее необходимо выполнять с правами суперпользователя root, а "$" -- с правами любого пользователя системы.)
Первый пакет посредством PAM (Pluggable authentication modules) позволит авторизировать пользователей в системе, основываясь на их данных из OpenLDAP, а второй -- использовать дополнительную информацию из LDAP-директорий.
Далее был настроен конфигурационный файл системного LDAP-клиента (/etc/ldap. conf). Его содержимое (для подключения к LDAP-серверу кафедру) приняло такой вид:
host 10.0.0.180
base dc=eva, dc=miem, dc=edu, dc=ru
ldap_version 3
port 389
scope sub
pam_login_attribute uid
ssl no
Для того, чтобы PAM работал с LDAP, конфигурационный файл /etc/pam. d/system-auth был приведен к следующему виду:
auth required pam_env. so
auth sufficient pam_unix. so likeauth nullok shadow
auth sufficient pam_ldap. so use_first_pass
auth required pam_deny. so
account sufficient pam_unix. so
account sufficient pam_ldap. so
password required pam_cracklib. so retry=3
password sufficient pam_unix. so nullok use_authtok md5 shadow
password sufficient pam_ldap. so use_authtok use_first_pass
password required pam_deny. so
session required pam_limits. so
session required pam_unix. so
session required pam_mkhomedir. so skel=/etc/skel/
session optional pam_ldap. so
Вызов pam_mkhomedir. so в session требуется для автоматического создания домашнего каталога пользователя, если такового еще не существует в системе (так называемый "скелет", т. е. содержимое этого каталога по умолчанию, берется из системной директории /etc/skel).
Затем необходимые поля конфигурационного файла NSS (/etc/nsswitch. conf) были дополнен значением "ldap" для того, чтобы система брала данные о пользователях, их паролях и группах не только из файлов, но и LDAP. Первые строки файла приняли следующий вид:
passwd: compat ldap
shadow: compat ldap
group: compat ldap
После выполнения этих шагов среди пользователей системы появились и записи из LDAP, у которых были прописаны все необходимые опции для posixAccount. Проверяется это командой, выводящей полный перечень пользователей системы:
$ getent passwd
(В ее выводе теперь присутствуют записи из LDAP вида: Имя. Фамилия:*:UID:GID:Имя. Фамилия:/home/год_выпуска/Имя. Фамилия:/bin/bash.)
Этап 2. Установка FTP-сервера
Установка пакета с FTP-сервером ProFTPD в Gentoo Linux осуществляется командой:
# emerge proftpd
Поскольку для связи авторизации в FTP-сервере через данные в LDAP нужен модуль mod_ldap, перед выполнением этой команды необходимо удостовериться в том, что в переменной окружения USE присутствует значение ldap. Добавить его можно правкой соответствующей строки файла /etc/make. conf или такой командой:
export USE="ldap"
После установки ProFTPD в его конфигурационном файле (/etc/proftpd/proftpd. conf) были проведены необходимые для связи с LDAP изменения -- добавлены следующие строки:
LDAPServer 10.0.0.180
LDAPDoAuth on "dc=eva, dc=miem, dc=edu, dc=ru"
LDAPDefaultAuthScheme clear
Кроме того, в конфигурационном файле были заданы принятые для системы настройки пользовательского каталога по умолчанию (его домашняя директория) и максимально доступного по FTP каталога в файловой системе (чтобы никто не смог просмотреть содержимое жесткого диска выше по структуре файловой системы, чем в общем /home), а также предусмотрено автоматическое создание домашнего каталога пользователя, если такового еще не существует в системе (аналогично случаю с pam_mkhomedir. so):
DefaultRoot /home
DefaultChdir ~
CreateHome on 755 skel /etc/skel/ dirmode 755
Демон ProFTPD был запущен командой:
# /etc/init. d/proftpd start
Таким образом, FTP-сервер был подготовлен к работе: все пользователи кафедры получили возможность заходить на ftp://share. ***** посредством своих данных из LDAP, размещать на нем свои файлы и скачивать загруженные другими пользователями.
Этап 3. Установка Apache с mod_ldap
Установка пакета с HTTP-сервером Apache была произведена командой:
# emerge =net-www/apache-2.0.58
В конфигурационный файл Apache (/etc/apache2/httpd. conf) были добавлены необходимые для авторизации модули:
LoadModule auth_module modules/mod_auth. so
LoadModule ldap_module modules/mod_ldap. so
LoadModule auth_ldap_module modules/mod_auth_ldap. so
Для единственного используемого виртуального хоста была произведена настройка файла /etc/apache2/vhosts. d/00_default_vhost. conf. Изначальное принятое решение для «красивого» отображения содержимого каталогов пользователей (с использованием опций модуля mod_autoindex [3]) ввиду ограниченности возможностей было заменено на собственный PHP-скрипт (go. php, о его работе подробно написано в этапе 4):
NameVirtualHost *:8080
<VirtualHost *:8080>
ServerName share. *****
DocumentRoot "/home"
Alias /shtml/ /var/www/trash/shtml/
<Directory "/home">
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} - d [NC]
RewriteRule ^.*$ /php/go. php [NC, NE, L]
AddType plain/text. php. php3 .php4 .php5 .phps. phtml
AllowOverride None
Order allow, deny
Allow from all
</Directory>
</VirtualHost>
Кроме того, были созданы дополнительные каталоги:
- /home/pub (с правами 7каталог с файлами для всеобщего доступа (даже для пользователей, не имеющих доступа для авторизации в сервисе через LDAP); /home/private (с правами 7каталог с файлами для всех авторизованных через LDAP пользователей; /home/temp (с правами 7временный каталог с файлами для всех авторизованных через LDAP пользователей (его содержимое удаляется автоматически ежедневно ночью).
Этап 4. Установка PHP, написание Web-интерфейса
Установка пакета с PHP была произведена командой:
# emerge php
В PHP-скриптах для проверки авторизации и получения группы текущего авторизованного пользователя было решено не выполнять лишние обращения к LDAP. Для решения этой проблемы был создан shell-скрипт, прописанный в crontab системы на выполнения каждые 15 минут. Вот его содержимое (genhtaccess. sh):
#!/bin/sh
ls - dR /home/20[0-9][0-9]/* /home/kafedra/* /home/external/*\
| sed "s/\/home\///" > /var/www/trash/php/.db. txt
Предназначение genhtaccess. sh -- генерирование файла (/var/www/trash/php/.db. txt) со списком всех "зарегистрированных" в системе пользователей (т. е. тех, кто хотя бы однажды заходил по FTP или HTTP под своим логином).
Чтобы загруженные пользователями PHP-файлы не исполнялись при их просмотре через Web, в секцию <Directory "/home"> файла /etc/apache2/vhosts. d/00_default_vhost. conf была добавлена следующая строка:
AddType plain/text. php. php3 .php4 .php5 .phps. phtml
Кроме того, в этом же файле для будущего PHP-скрипта авторизации внутри секции VirtualHost был создан такой подраздел:
<Location "/auth. php">
AuthName "Private zone"
AuthType Basic
AuthLDAPURL ldap://10.0.0.180/dc=eva, dc=miem, dc=edu, dc=ru? uid
require valid-user
</Location>
Скрипт для авторизации пользователей (/var/www/trash/php/auth. php):
<?
$login = $_SERVER['PHP_AUTH_USER'];
if (isSet($login)){
list($first, $second) = split("\\.", $login);
$login = ucfirst($first).".".ucfirst($second);
$year = 0;
if (file_exists(".db. txt")){
$fh = fopen(".db. txt", "r");
while (!feof($fh)){
list($tyear, $cur) = split("/", fgets($fh));
if (strcmp($cur, $login."\n") == 0){ $year = $tyear; break; }
}
fclose($fh);
}
if ($year == 0){
system("userhome=`getent passwd|grep $login |cut - d ':' - f 6`\
&& /bin/mkdir \$userhome && /bin/cp - R /etc/skel/* \$userhome\
&& /bin/chown - R $login:users \$userhome\
&& /opt/shurup/gen/genhtaccess. sh");
header("Location: http://".$_SERVER['SERVER_NAME']);
} else {
$url = "/".$year."/".$login."/";
header("Location: http://".$_SERVER['SERVER_NAME'].$url);
}
}
?>
Исполнение этого файла осуществляется только после авторизации через LDAP средствами mod_ldap. Скрипт проверяет, входит ли пользователь на сервер впервые (по данным из /var/www/trash/php/.db. txt). Если это так, то перед пересылкой в домашний каталог пользователя, скрипт предварительно добавляет соответствующую запись. db. txt shell-скриптом genhtaccess. sh.
Для реализации web-интерфейса были написаны следующие PHP-скрипты:
- /var/www/trash/php/go. php -- скрипт вывода содержимого текущего каталога с учетом прав пользователя (для этого в нем создается дочерный процесс, которому присваиваются права текущего авторизованного пользователя, а наличие прав доступа к каталогам и файлам проверяется с помощью PHP-функции posix_access(); подробности о разграничении прав рассмотрены в следующем разделе); /var/www/trash/php/menu. php -- генерирование меню с формой для выполнения различных операций над файлами/каталогами; /var/www/trash/php/manage. php -- базовый скрипт для работы с файлами, осуществляющий функции по загрузке файлов, удалению/переименованию каталогов и файлов, созданию каталогов.
Этап 5. Интеграция домашних страниц пользователей
Каждому пользователю из LDAP предоставлена возможность создания простого сайта (статические HTML и PHP-скрипты с определенными ограничениями) с адресом вида http://имя. фамилия. год_выпуска. homepage. ***** (например, [1]). В домашнем каталоге каждого пользователя для этого создан каталог /homepage (добавлен в /etc/skel с правами 775).
Переадресация была реализована с помощью web-сервера <a href="http://*****/nginx/">nginx</a>. Выдержка из его конфигурационного файла (/etc/nginx/nginx. conf):
location / {
set $rewrite yes;
if ($host ~* "([a-z])([a-z]+)\.([a-z])([a-z]+)\.([a-z0-9]+)\.homepage\.auditory\.ru" ) {
set $year $5;
set $fl_name $1;
set $name $2;
set $fl_sname $3;
set $sname $4;
}
if ($rewrited = yes) {
set $rewrite no;
}
if ($rewrite = yes) {
set $rewrited yes;
rewrite ^\/(.*)$ /$year/$fl_name_c$name.$fl_sname_c$sname/homepage/$1 last;
}
В настройки используемого виртуального хоста (/etc/apache2/vhosts. d/00_default_vhost. conf) добавлены соответствующие сведения для возможности запуска PHP-скриптов из каталогов для домашних страниц:
<Directory "/home/*/*/homepage">
AddType application/x-httpd-php. php. php3 .php4 .php5 .phtml
php_admin_flag safe_mode 1
php_admin_value safe_mode_exec_dir /home
php_admin_value disable_functions phpinfo, system
</Directory>
Параметры php_admin_* включают защищенный режим PHP [6] для предотвращения потенциальных угроз в безопасности со стороны пользовательских скриптов.
Этап 6. Разграничение доступа с помощью ACL
Общие сведения о списке прав доступа
Список прав доступа (Access Control List, ACL) [7] -- это концепция безопасности, используемая для разделения привилегий. Суть ее заключается в том, что всякий раз, когда происходит обращение к тому или иному ресурсу, перед тем, как выполнить запрос, производится проверка на наличие у данного объекта (или группы объектов) соответствующих прав.
По умолчанию в UNIX используются ограниченные возможности ACL: на каждый файл/каталог могут устанавливаться права трех типов (чтение [r], запись [w] и исполнение [x]) для владельца (owner), группы пользователей (group) и всех остальных (other). И на "среднестатистической" машине обычно не нужен весь функционал, однако в нашем случае с созданием ЕФП кафедры возникла такая потребность.
В POSIX ACL [8], поддержка которого появилась в Linux-ядре начиная с релиза 2.5.46 (ноябрь 2002 года), списки стандартных UNIX-прав называют "минимальными". С помощью включения поддержки этой технологии появляется возможность добавления "расширенных" списков.
Это означает, что в таком случае помимо указания прав (r, w, x) для трех обычных типов (owner, group, other) такие права могут быть дополнительно заданы и для любых других пользователей (named user) и групп пользователей (named group). Третье появляющееся дополнительное поле -- маска (mask) -- позволяет ограничивать возможность выделения каких-либо прав (r, w, x) всем пользователям. Маска выполняет функцию своеобразного фильтра: все типы прав, которые в ней не заданы, не могут быть разрешены пользователям в данном "расширенном" ACL. (Например, если права пользователя joe на данный файл -- rwx, а маска -- r-x, то реальные права, которыми будет обладать joe, -- это r-x.)
Таким образом, POSIX ACL позволяет создать гибкую систему прав доступа, необходимую для единого файлового пространства кафедры.
Включение поддержки POSIX ACL
Для включения поддержки POSIX ACL в Gentoo Linux [8] в первую очередь был установлен пакет acl:
# emerge - v acl
После этого необходимо добавить соответствующую возможность в Linux-ядре. Для используемого на сервере Linux-ядра версии 2.6.17 и файловой системы XFS это делается включением опции File systems -> XFS filesystem support -> XFS POSIX ACL support. Ядро нужно вновь собрать, а затем загрузиться с нового образа.
В результате в системе появились утилиты getfattr и setfattr [10], позволяющие получать информацию о POSIX ACL и изменять ее соответственно.
Теперь для того, чтобы, например, выдать пользователю shurup права на чтение и запись для хранимого в текущем каталоге файла mod_suphp-0.6.1-r2.ebuild, достаточно ввести команду:
# setfacl - m u:shurup:rw mod_suphp-0.6.1-r2.ebuild
После ее выполнения к данному файлу, владельцем которого является root:root и режим которого был установлен в 600, с правами на запись и чтение сможет обращаться и пользователь shurup, не входящий в группу root. Проверить это просто. Вывод команды:
# getfacl mod_suphp-0.6.1-r2.ebuild
-- подтверждает расширение привилегий для файла:
# file: mod_suphp-0.6.1-r2.ebuild
# owner: root
# group: root
user::rw-
user:shurup:rw-
group::r--
mask::rw-
other::---
Таким образом, появилась возможность управления расширенными правами на сервере путем устанавления соответствующих POSIX ACL на любые пользовательские файлы и каталоги.
Заключение
Результатом выполнения курсовой работы стало создание единого файлового пространства кафедры ЭВА -- сервера share. *****, ставшего базой для инфраструктуры хранения на жестком диске данных всех пользователей из LDAP. Сервер, будучи единым удобным хранилищем и доступным различными способами (FTP, HTTP, а в перспективе и SVN), предоставляет продвинутые возможности для хранения файлов и обменами ими, а также совместной работы пользователей.
Список использованной литературы
Андрей Коврин "Авторизация через pam_ldap в Gentoo Linux". Электронное приложение "Open Source" к журналу "Системный администратор", выпуск 007, 2006. Benjamin Coles и коллектив редакторов (Sven Vermeulen, Brandon Hale, Benny Chuang) "Gentoo Guide to OpenLDAP Authentication". Gentoo Linux Documentation. Apache 2.0 Module mod_autoindex. The Apache Software Foundation, 2006. Apache 2.0 Module mod_ldap. The Apache Software Foundation, 2006. Документация по nginx. Игорь Сысоев, 2006. "Глава 42. Защищенный режим", руководство по PHP. The PHP Group, 2006. Access control list на Wikipedia. POSIX Access Control Lists on Linux. Nikos Drakos (1993, 1994, 1995, 1996) и Ross Moore (1997, 1998, 1999). Перевод на английский -- Andreas Gruenbacher, 2003. HOWTO Use filesystem ACLs. Gentoo Linux Wiki, 2006. Linux EA/ACL manual pages. Andreas Grunbacher, 2000.Плейлист для видео каталога
Материал из Scientific journal.
Перейти к: навигация, поиск
Содержание[убрать]
|
Аннотация
Значение веб-приложений для информационного общества постоянно растет. Веб-приложения - это будущее Веба, программных приложений, сетевых архитектур и даже компьютеров и операционных систем. Приложения основанные на Вебе проникнут (почти) во все виды программ, которыми мы пользуемся сегодня. Естественно, растущие потребности, требуют новых затрат, ресурсов и технологий. Анализирую современные разработки и существующие методы, определим наиболее перспективные из них, работа с которыми упрощает и способствует развитию систем "интеллектуального интерфейса" и работы в web.
Информация о проекте и поставленные задачи
Общая информация о проекте. Данный проект является частью телевизионный информационной системы кафедры ЭВА. Система приема видео включает в себя: преобразование принятого формата, создание каталога для размещения принятых файлов и, наконец, система организации телевещания из этого каталога, так называемы – “playlist”. В данной статье будет рассмотрена разработка одного из ее составляющих – создания “playlist”. Данная система будет расположена и функционировать в сети Internet. Поэтому при ее создании будут учтены особенности среды, в которой будет функционировать система. Система функционирования и организации указанного проекта базируется на данных, получаемых из каталога видео. При его создании, помимо разработки эффективной программной части, одной из наиважнейших систем является организации продуманного, эргономичного и понятного пользовательского интерфейса. Соответственно, процесс создания “playlist” можно разделить на 2 части: создание технической части и пользовательский интерфейс. Невозможно определить какая из задач наиболее важна или первостепенна. Поэтому каждая из частей требует тщательного анализа и проработки деталей. Для того чтобы процесс разработки был наиболее эффективен, было произведено разделение проекта на техническую и интерфейсную части. Первой частью занимается Дмитрий Воробьёв, второй – Александр Баталов.
Подробное рассмотрение частей, составляющих проект. Рассмотрим каждую из частей в отдельности и более подробно. Кратко интерфейсную часть можно описать следующим образом:Основой акцент в интерфейсной части будет сделан на систему графического управления. Система управления и навигации будет напоминать стандартную систему, используемую в таких крупных продуктах как: Microsoft Office и Microsoft Windows. Такая стилистика наиболее приемлема, так как навыки, необходимые для управления ей присутствует практически у любого пользователя ПК, что позволит сделать систему простой и понятной пользователю. В создаваемой системе будет существовать следующие возможности:
• Добавление ссылок путем перемещения между окнами браузера и элементами каталога.
• Изменения позиции ссылки в “playlist”, путем перемещения их манипулятором (мышью).
• Отработка горячих клавиш, для выполнения операций: копирования, удаления, переключениями между каналами и т. п.
• Будет организована система предварительного просмотра интересующего фрагмента.
• Просмотр прямого эфира вещания.
• Дополнительные информационные элементы, такие как часы и служебная информация обрабатываемого файла.
При создание данного интерфейса будут использованы: средства HTML, средства Javascript, PHP, MYSQL. Возможно применения готовых, свободно-распространяемых скриптов, модулей и программ, предназначенных для организации интерфейса управления. Для обеспечения наиболее эффективной работы, данные, с которыми работает пользователь, будут публиковаться с учетом природной способностью человека воспринимать информацию. Структура будет такова, что она будет легка и приятна как человеческому глазу так и его сознанию.
Разработка интерфейса.
Общие тенденции в создании web-интерфейсов.
В настоящее время разработка WEB приложений стремится к разграничению клиентской части и серверной, этим и обуславливается повсеместное использование шаблонов, таких как Smarty и XSLT. Сейчас проекты становятся сложнее, и переплетать между собой различные технологии становиться слишком дорого для времени разработчика. Так, например, все стили форматирования выносятся в CSS или в XSL файлы, HTML или XML данные хранятся в других разделах, серверные обработчики в третьих, базы данных в четвертых. И если еще 5-6 лет назад практически везде можно было увидеть переплетение всего этого в одном файле, то сейчас это все чаще становиться редкостью. При разработке более сложных проектов возникает необходимость в структурированности и удобочитаемости кода. Не следует засорять код программиста кодом верстальщика, а код верстальщика - правками дизайнера, и так далее. Возникает необходимость в разграничении работы. Так, например, дизайнер будет делать свою работу, верстальщик свою, программист свою, и при этом никто друг другу мешать не будет. В итоге каждому участнику проекта достаточно будет знать только те данные, с которыми ему придется работать. В таком случае производительность группы и качество проекта повышается в разы. В настоящее время эта проблема с успехом решается путем использования шаблонов, однако это тоже создает определенные трудности.
Рассмотрение среды Java Script
Анализирую проекты, направленные на работу подобных систем, было выяснено, что подобных систем в свободном распространении не существует. Те же не многое проекты, которые имеют коммерческую основы, имеют достаточно скудное описание в области реализации их интерфейса, в большинстве своем ограниченное скриншотами программы, далеко не лучшего качества. Поэтому останавливаться на рассмотрении этих программ смысла не имеет. Ограничусь привидением ссылок на их документацию в списке литературы. Исходя из вышеупомянутого, следует, что для разработки и создания интерфейса, необходима разработка собственного интерфейса, со своей логикой и системой функционирования. На сегодняшний день, все веб-приложения работают по протоколу HTTP, по схеме клиент-сервер. То есть пользователь получает данные и далее, после внесения информации или ее изменений, они отправляются на сервер. В результате, вместо того, чтобы целиком сосредоточится на работе с данными, обработать их полностью, и по завершению всех этапов преобразования, сохранить изменения на тот же сервер, пользователю приходится периодически отправлять данные на сервер, зачастую для проведения абсолютно примитивных операций, например проверка правильности введенного e-mail. На практике это означает сплошные неудобства: ошибки при передачи данных, ошибки в введенной информации и, самое главное, потраченные нервы и время пользователя. Все это приводит к ухудшению качества трудовой деятельности и снижению продуктивности. Для того чтобы хоть как-то облегчить работу с приложениями был создан клиентский язык – Javascript. Благодаря ему существует возможность, для перенесения определенного количества программной логики в HTML-страницу, что ускорит реакцию на действия пользователя. Но здесь есть один недостаток. Одна из проблем заключается в том, что как только JavaScript попадает в браузер пользователя, программная логика доступна для просмотра невооруженным глазом. До некоторой степени это не угрожает проекту, но при передачи конфиденциальной информации, такое решение, зачастую, невозможно. Вторым аспектом, который не способен решить Java Script заключается в том, что серьезную программную логику в страницу поместить невозможно. Интерфейс для этого просто не предназначен. Вся логика должна находиться на уровне приложения, а это значит, приходится возвращаться на сервер. Сложности вызывает и тот факт, что Java Script поддерживается далеко не всеми браузерами или не все пользователи включают ее поддержку. Поэтому проверка или обработка данных, реализация программной логики должны обрабатываться на сервере. Очевидно, что функций Java script, в последнее время стало совершенно недостаточно, так как процедуру передачи и получения информации между сервером и клиентом язык упростить не смог. Передача существовала по средствам методов GET и POST. Но на сегодняшний день существует объект языка Java Script – XMLHttpRequest. Этот объект впервые был реализован компанией Microsoft в виде объекта ActiveX, но сейчас он доступен как встроенный объект в некоторых браузерах. Этот объект позволяет с использованием JavaScript-у осуществлять HTTP-запросы к удаленному серверу без необходимости перезагружать страницу. По сути HTTP-запросы отправляются и получаются полностью вне страницы, а пользователь их даже не замечает. Это позволяет достичь создания быстрого пользовательского интерфейса с сохранением при этом программной логики на сервере. Но технология на сегодняшний день еще не стандартизована, поэтому в различных браузерах она работает по разному, либо не работает вовсе.
Ajax технология
Однако, лишь средствами XMLHttpRequest, возможно ускорить работу приложения, но улучшить интерфейс и создать иную систему работы с ним – невозможно. Таким прорывом и есть AJAX (Asynchronous JavaScript and XML) - подход к построению пользовательских интерфейсов веб-приложений, при котором web-страница, не перезагружаясь, сама догружает нужные пользователю данные. AJAX - один из компонентов концепции DHTML. Впервые об Ajax заговорили после появления в феврале 2005-го года статьи Джесси Джеймса Гарретта "Новый подход к веб-приложениям". Ajax - это не самостоятельная технология. Это идея, которая базируется на двух основных принципах. Использование DHTML для динамичного изменения содержания страницы. Использование XMLHttpRequest для обращения к серверу "на лету". Использование этих двух подходов позволяет создавать намного более удобные WEB-интерфейсы пользователя на тех страницах сайтов, где необходимо активное взаимодействие с пользователем. Использование Ajax стало наиболее популярно после того, как компания Google начала активно использовать его при создании своих сайтов, таких как Gmail, Google maps и Google suggest. Создание этих сайтов подтвердило эффективность использования данного подхода.
Итак подробнее: если взять классическую модель WEB-приложения:
Клиент, набирая в строке поиска адрес интересующего его ресурса, попадая на сервер, делает к нему запрос. Сервер производит вычисления в соответствии с запросом, обращается к базе данных и так далее, после чего полученные данные идут клиенту и, в случае необходимости подставляются в шаблоны и обрабатываются браузером. Результатом является страница, которую мы видим, и которую 80% населения страны находящейся в WEB называют Интернетом. Это классическая модель, которая успела себя зарекомендовать и заслужить себе почетное место под солнцем. Это самая простая модель взаимодействия и, как следствие, самая распространенная. Однако ее все чаще становиться недостаточно.
Теперь посмотрим на модель взаимодействия AJAX:
Последовательность действий клиента сохраняется и он, скорее всего не поймет того, что будет происходить, а слово AJAX будет ассоциироваться только с названием футбольного клуба. Но на стороне сервера все выглядит иначе. При обращении к серверу, генерируется страница, которая будет отображаться пользователю, и предлагать ему совершить интересующую его последовательность действий. При сознательном (хотя и не обязательно) выборе клиента, его запрос будет обращаться к AJAX модулю, который и будет производить все интересующие его вычисления и работу с сервером как таковым. Но в чем же новшество? Основное отличие в том что этот метод дает нам возможность динамически обращаться к серверу и выполнять интересующие нас действия. Например, нам нужно выполнить обращение к базе данных и получить интересующие нас данные которые затем будем использовать. Данные мы будем хранить в XML файле который будет формироваться динамически. Так мы можем получить и обработать данные, полученные из БД, или что-нибудь другое необходимое нам. К тому же сервер будет обрабатывать только те данные, которые нам необходимо обновить, а не всю страницу в случае ее перезагрузки.
ПРИМЕР:
Представьте себе, on-line игру "Морской бой", в которую играют два закоренелых друга - житель ЮАР и житель Японии. Как с помощью такой модели сделать их игру максимально приятной? В любом случае данные потопленных кораблей будут хранится на сервере, и что бы проверить не походил ли оппонент, необходим будет каждый раз обновлять страницу и подгущать устаревшие данные. "Но ведь люди придумали кэширование" - скажете вы и будете абсолютно правы, но легче от этого не становиться. Кэширование всего лишь ускорит время взаимодействия с сервером, но не избавит от необходимости перезагружать страницу. Как вариант можно поставить определенное время самообновления, но и в этом случае страница будет перезагружаться полностью.
Ввиду появления Ajax, мы можем сделать следующее: поставить проверку в течении каждых трех секунд XML файла данная проверка подразумевает под собой проверку базы данных на предмет новой записи, то есть - сделанного оппонентом хода. Если ход был сделан, страница без перезагрузки топит корабли, тем самым, портя настроение участникам водных баталий. Данная функциональность достигается элементарным использованием Javascript и таблиц стилей. Этот пример достаточно наглядный, однако далеко не полный, применение данной технологии гораздо существенней.
отрицательные черты Ajax и средсва их устранения.
- Во-первых - мы можем передавать данные только методом GET, соответственно большие объемы данных придется оставить в покое. Данная проблема имеет решения, путем использования Сookies, которые вполне приемлемы в случаях передачи больших данных, чем может вместить в себя GET запрос, а Javascript в свою очередь имеет функции для работы с ними.
- Вторая проблема - кросс-браузерность. Объект XMLHttpRequest еще не является частью какого-либо стандарта (хотя нечто подобное уже было предложено в спецификации W3C DOM Level 3 Load and Save). Поэтому существует два отличных друг от друга метода вызова этого объекта в коде скрипта. В Internet Explorer объект ActiveX вызывается так:
var req = new ActiveXObject("Microsoft. XMLHTTP"); В Mozilla и Safari это делается проще (так как там это объект, встроенный в JavaScript): var req = new XMLHttpRequest(); Все современные браузеры поддерживают данный объект и проблемы возникнут только у 1,8% пользователей (согласно данными статистики компании SpyLog), которые пользуются очень старыми версиями браузеров, не поддерживающими этот объект.
- И, наконец, защищенность. На этом остановимся поподробнее. Основная проблема заключается в том, что все данные и исходный код JavaScript функций можно увидеть путем просмотра исходного кода страницы, соответственно злоумышленник может проследить логику выполнения запросов и при определенном стечении обстоятельств выполнить необходимый ему набор команд. Это не играет особой роли, когда у нас идет простое сопоставление данных, но что делать в более сложных ситуациях, например при авторизации, и как в таком случае передавать пароли. Как уже было сказано выше, на помощь приходят Cookies. Необходимые данные можно пересылать с их помощью, так же их и обрабатывать.
AJAX с одной стороны - огромный скачок в WEB инженерии, но с другой стороны это давно назревавший этап эволюции, который открыл новые горизонты в сфере разработки программного обеспечения. В тоже время эта технология еще довольно "сыра". Но она постоянно развивается и улучшается, вместе с развитием Internet.
Класс RIA
Тенденция к усовершенствованию WEB интерфейсов постоянно заставляет крупные компании, работающие в этой сфере, разрабатывать и выпускать новые среды и модули. Одна из таких компаний – Adobe. Недавно она презентовала целый набор утилит и программ для разработки интерфейсов нового поколения. Называется этот набор Flex. Описывать систему самостоятельно считаю не целесообразным, поэтому приведу основные, наиболее важные характеристики, преимущества и отличия Flex, заявленные самим производителем.
Adobe Flex — технология для легкого и очень быстрого создания RIA, Rich (вот уж действительно rich) Internet Applications. Flex — это родственная Flash технология, основанная на описании интерфейса приложения (и не только: обработчиков событий, связи источников данных с объектами и т. п.) с помощью диалекта XML — MXML. Flex приложение может компилироваться на сервере, а может — из IDE [это стало возможным начиная с Flex 2], как во Flash, результатом является swf файл, исполняемый Flash Player, самой распространенной VM в галактике Млечный Путь и всех близлежащих.
Чем Flex отличается от Flash? Достоинства Flex тесно связаны с его спецификой, MXML. Без загрузки внешних роликов (а постоянно пользоваться ими или внедренными в виде поля класса объектами, как ни крути, не особо приятно) мы не можем создать настолько эффектного интерфейса, как это позволяет сделать Flash, но для многих задач присутствующего скинования как раз хватает. В случае со строгими интерфейсами бизнес-приложений скорость разработки просто потрясающая. Также Flex славен своими графиками, компоненты для построения которых сделаны не только удобными для использования, но и в 99% случаев выглядят очень приемлимо для использования as is. Пример — графики Google Analytics.
Копнув глубже, мы понимаем, что сила Flex-GUI в его фрэймворке (библиотека компонент), которая очень удачно спроектирована, вобрав в себя весь опыт предыдущих компонент (v1 components, v2 components, компоненты для Flex 1/1.5). Другая составляющая - это компилятор mxmlc, который превращает mxml-код в обычный AS3-код, который, в свою очередь, компилируется в swf. Таким образом, Flex-GUI представляет собой связку удачно спроектированного фрэймворка, заточенного под mxml, и компилятора mxmlc.
Достоинства Flex 2, помимо скорости разработки, предоставляет полные мультимедийные возможности Flash Platform : включая потоковое видео, звук (в том числе и программный), бинарные сокеты и большое число прочих новых возможностей ActionScript 3. Возможностей, которые, казалось бы, в 1.2 мегабайта запихать просто невозможно...
Недостатки Отдельные части Flex технологии являются платными.
Сравнение и интеграция AJAX и Flex
Компания Adobe упростит разработку веб-приложений на основе AJAX и Flex. Она выпустила две библиотеки с открытым исходным кодом, которые должны упростить процесс разработки веб-приложений, одновременно использующих технологии Flex, Flash и AJAX.
AJAX (Asynchronous JavaScript + XML - асинхронный JavaScript+XML) позволяет создавать веб-сайты, которые субъективно работают быстрее обычных. Ресурсы, построенные с применением технологии AJAX, позволяют выполнять многие действия без перезагрузки страницы. Это позволяет работать с веб-приложениями почти так же, как с традиционными программами. В настоящее время AJAX набирает всё большую и большую популярность среди разработчиков сайтов.
В свою очередь, Flex и Flash обладают рядом возможностей, которые отсутствуют у AJAX. В частности, поддерживаются работа с векторной графикой, кросс-доменный доступ к данным и прочее. Библиотеки Adobe как раз и должны установить своеобразный мост между Flex, Flash и AJAX.
Вывод
Современный расклад сил дает основание для следующего утверждения: Тенденции развития web-приложений направлены на то, чтобы работа с подобными приложениями была максимально продуктивна, понятна, удобна, экономична, имела возможность интеграции с существующими системами и разработками. Несомненно, на мой взгляд, выполнение и реализация подобных задач средствами, разработанными боле 20 лет назад уже не эффективна, а зачастую и невозможна. Будущие проектов, требующих адекватный интерфейс, работающий для пользователя и по его правилам, а не по правилам машины, за новыми технологиями. Технология компании Adobe - Flex, вполне может выступать в качестве современного средства для выполнения поставленных задач. Учитывая скорость развития web, можно с уверенностью сказать, что разработка интерфейса, например, для системы телевещания, отличная возможность для применения Flex технологии.
P. S. Прмеры разработок на Flex и дополнительная информация представлена на сайтах в списке литературы.
