Задачи будущего приложения:
- обслуживаниекаталогов электронных документов;
- предоставление доступа к каталогу каталогов электронных документов;
- управление раздачей и приемом электронных документов (приложение управляет процессом выдачи файлов, но не выдает оных).
Интерфейс пользователя посредством веб-браузера.
Ограничения:
- мультиплатформенность;
- OpenSource;
- минимальное потребление памяти;
- поддержка распределенности.
Пользователь должен иметь возможность:
- создавать/удалять каталоги;
- управлять атрибутами записей каталога;
- управлять разделами каталога;
- добавлять докуметы в каталог;
- удалять документы из каталога;
- редактировать атрибуты документов каталога;
- проводить поиск по атрибутам документов каталога;
- просматривать сруктуру разделов/подразделов каталога;
- загружать документы из каталога.
Авторизация и распределение полномочий при использовании каталога.
Данное приложение найдет применение в качестве универсальной библиотеки у кажого владельца даже не сильно большой коллекции электронных книг, софта, музыки, видео и т.д..
Занимаюсь разработкой и реализацией в свободное время. Проэкт достаточно сложный, но собираюсь доучить все необходимое по мере разработки и реализации.
Реализовывать собираюсь так.
Приложение написано на Tcl как единый http/ftp-сервер с поддержкой шифрования. Применяется объектно-ориентированный подход. Страницы беб-сайта генерируются tcl-скрипатми, статически встроенными в бинарник сервера. Файлы управляются либо встроенным ftp-сервером, либо внешним, который поддерживает хранение данных аутенификации в таблицах MySQL(или иной БД). Информация о каталогах, их структуре и атрибуты документов храниться на паросторах базы данных.
Для успешного выполнения проєкта необходимо владеть заниями и умениями программирования в области следующих языков и технологий: Tcl, HTML, CSS, Java Script, протоколы http и ftp, базы данных MySQL и sqlite3.
Прошу помосчи у энтузиастов, владеющих или желающих овладеть вышеуказанными знаниями и готовы применить их на реальном примере.
Как говориться, вместе мы – сила!
Ход событий планирую освещать в этой темме.
21 марта 2009 в 17:04
Удалось воспользоваться Rational Rose Enterprise Edition v2001a. Решено остановиться и отложить все, что уже было сделано.
Использование Rose позволило оценить сложность проекта и одновременно разбить на несколько логических частей для распределения усилий.
—–С этого момента начинаю проект с чистого листа.—–
Rational помог наглядно описать разделение программы на несколько частей:
I. mod
1. db
a. mysql
b. sqlite3
2. fs
3. srv
a. http
b. ftp
4. int
a. www
b. pda
c. wap
II. core
III. other
Краткое описание:
I) Mod – общий класс модулей:
1) db – (от DataBase) – через него работаем с любой базой данных;
2) fs – (от FileSystem) -работает с файловой системой;
3) srv – (от Server) – принимает запросы клиентов и отдает им ответы;
4) int – (от Interface) – определяет возможные варианты предоставляемых интерфейсов, занимается генерированием результата запроса в требуемый клиенту вид.
II) Core – собственно класс самого сервера; администратор, запускающий движок сервера, будет иметь доступ только к этому классу; предназначен для управления работой модулей и обеспечения взаимодействия между ними; хранит общие переменные.
III) Other – все остальные вспомогательные общие(!) мелкие классы, которыми пользуются mod/* и Core в процессе своей работы.
Каждый модуль должен требовать доступ только к переменным и процедурам Core, даже если эти переменные и процедуры являются лишь ссылками на подобные в других модулях.
На этом этапе могу оценить степень сложности проекта. Впечатляет, даже не думал, что имею такие амбиции
. Буду рад, если кто-нибудь захочет заняться реализацией даже одного из модулей.
Буду рад принять помощь в реализации задуманного от владеющих навыками разработки веб-сайтов (интерфейс, все-таки, через браузер в виде страничек сайта).
19 марта 2009 в 13:04
Уважаемые програмисты г.Харькова: помогите, пожалуйста, достать IDE для UML моделирования.
12 марта 2009 в 8:04
Давай встретимся в политехе, я 90% присоединюсь к проекту.
12 марта 2009 в 4:05
Итак, немного о процессе продвижения. Пишу то, что считаю необходимым.
Название, редакция 1: библиотека электронных документов.
Слово "библиотека" выбрано в связи с тем, что сервис должен предоставлять доступ не только к каталогу файлов, но и к самим файлам. Без предоставления файлов сервис смело мог называться "каталогом."
Слова "электронных документов", а не "электронных файлов", именно потому, что база предназначена для хранения любых пользовательских документов в электронном виде. Словосочетания "электронный файл" и "электронный документ" в моем понимании имею разную смысловую нагрузку. Если "электронный файл" означает просто совокупность бит информации (бессмысленная инфа никому не нужна), то выражение "электронный документ" вызывает любопытство по поводу наличия таких важных атрибутов как: название, автор, аудитория возcтребованости и т.д. Т.е. "документ" имеет более близкую человеку смысловую нагрузку, и более конкретную, нежели понятие "файл".
Размышления привели к необходимости разделения на следующие логические части:
1) движок приложения;
2) движок работы с базой данных каталога;
3) движок работы с файлами каталога;
4) движок взаимодействия с пользователями;
5) движок взаимодействия с себе подобными библиотеками.
1) ДВИЖОК ПРИЛОЖЕНИЯ.
Это основа приложения. Движок, собственно, пишется полностью на Tcl. Вроде и так ясно.
2) ДВИЖОК РАБОТЫ С БАЗОЙ ДАННЫХ КАТАЛОГА.
База данных хранит список всех документов и их атрибутов.
После некоторых раздумий в качестве базы данных решено использовать на выбор sqlite3 или mysql.
Наличие выбора было сделано намеренно: MySQL – для сетевых реализаций, sqlite3 – для тех, кто в танке. Эти базы данных общедоступны, широко разпостранены, многими изучены, имеют продвинутую функциональность, удовлетворительную производительность и являются OpenSource. К тому же пакеты расширения для доступа к этим базам данных существуют для Tcl. Пакеты расширения в виде динамических библиотек, поэтому не предоставляют мне простора для экспериментов, но этого от них и не требуется, так как эти пакеты необходимы лишь в качестве моста к "складу" информации. Этого нам и надо.
3) ДВИЖОК РАБОТЫ С ФАЙЛАМИ КАТАЛОГА.
Каталог, собственно, существует именно для классификации обслуживаемых документов. А полезной информацией являются именно электронные документы. В компьютере они представляются в виде файлов. Следовательно, необходимо научить программу работать с этими файлами. Можно было бы хранить и файлы в самой базе данных вместе с каталогом, но такой сценарий имеет множество недостатков, учитывая которые отказываюсь от подобной затеи. Файлы должны где-то храниться, как-то загружаться в базу и выдаваться из базы. Решено за пределы возможностей веб-браузера не выходить.
Загрузку файлов в библиотеку можно реализовать посредством передачи файла прямо из веб-формы клиентов, выполненной на простом html. Т.е. это реализовано в самом http протоколе, который вполне подходит и для загрузки файлов в библиотеку. Но согласно информации, которой владею, этот протокол имеет недостатки, основным из которых является плохая ориентированность на работу c файлами больших размеров. Удельная масса запросов клиентов при работе с библиотекой направлена на работу именно с каталогом, а не с содержимым библиотеки, для работы с которым существует много более эффективных инструментов. Первая встречная мысля указала на ftp протокол, широко разпостраненный и не требующий почти никаких знаний для владеющих опытом работы в интернете. Есть одно НО – нынче разпостраненные браузеры умеют только читать информацию по этому протоколу, т.е. смогут только прочитать файлы из базы, но не загрузить в нее. Учитывая что библиотека в основном будет выдавать документы, можно смириться с недостатками http при загрузке файлов на сервер.
12 марта 2009 в 4:05
А для выдачи документов сервером вполне подходит ftp. Пакет расширения для Tcl реализован в виде текстового кода и вмещается в 60кб, разобраться в которых не составляет труда. Можно было бы повысить производительность и вдобавок получить множество уже созданной функциональности применив внешний ftp сервер. Учитывая необходимость распределения и контроля доступа самим движком библиотеки, такой ftp-сервер должен поддерживать хранение данных аутентификации во внешнем хранилище, к примеру во внешней базе данных. Реализации подобной функциональности я нашел только под *nix системы, но ориентируюсь и на окна, под которыми работает большинство сотрудников моего универа (даже центральный интернет-сервер на окнах вертится). Решено было использовать ftp-сервер собственной реализации. К тому же появилась мысль о целесообразности выделения ftp в отдельное приложение и разрабатывать параллельной командой с заточкой под основное приложение (тут необходима поддержка единомышленников, отзовитесь, пожалуйста).
4) ДВИЖОК ВЗАИМОДЕЙСТВИЯ С ПОЛЬЗОВАТЕЛЯМИ.
Используется веб-протокол http, по которому пользователь получает доступ к интерфейсу работы с сервисом. Решено было не ломать голову над разработкой http сервера, поскольку готовое решение уже существует для Tcl. За основу http-сервера был взят пакет расширения tclhttpd. Он полностью реализован в текстовом коде (360кб), а это – значительный толчок в изучении и полная свобода в экспериментах при разборе этого протокола.
5) ДВИЖОК ВЗАИМОДЕЙСТВИЯ С СЕБЕ ПОДОБНЫМИ БИБЛИОТЕКАМИ.
Резонным возникает вопросс обмена содержимым между разными библиотеками или объединение нескольких библиотек воедино.
Проработку этой части решено оставить "на потом" до лучших времен. Идея такова:
- offline обмен: результатом экспорта затребованных документов будет sqlite3-файл (копия каталога экспортированных документов), и директория файлов (содержащая файлы документов, затребованных для экспорта). Для импорта библиотекой-приемником достаточно указать путь к файлу-каталогу и путь к директории экспортированных файлов;
- online обмен: от библиотеки источника по тому же http-протоколу в библиотеку-приемник передается информация об атрибутах документа и прямая ftp-ссылка. Библиотека-приемник закачивает файл на свои просторы и приступает к обработке следующего документа.
- online-дополнение:
а) при соединении нескольких библиотек каждая создает временную/постоянную копию каталога (не файлов) подключенной библиотеки. Ссылки на результирующие файлы документов в результатах поиска одного сервера будут содержать пути на файлы, реально расположенные на других библиотеках.
б) поисковый запрос исходным сервером библиотеки дублируется на серверы подключенных к нему библиотек. Поисковый запрос будет содержать также и результат, выданный другими серверами.
План начальных действий таков:
- запастись литературой по ftp/http;
- разобрать функционирование пакета расширения tclhttpd (реализация http-сервера);
- переделать tclhttpd под свои функциональные потребности;
- дополнить и оптимизировать http-сервер своими скриптами, которые станут движком сервера;
- дополнить движок процедурами работы с базами данных;
- разобрать пакет расширения ftpd (реализация ftp-сервера);
- переделать ftpd под свои нужды.
Движок решено было писать с применением принципов ООП, реализовать который поможет пакет расширения XOTcl, но с первого захода разобраться в tclhttpd и переделать его под XOTcl у меня не получилось. После недолгих раздумий принято пойти следующим путем: написать движок по обычному процедурному методу программирования, после чего переделать его под ООП. Прием и выдачу файлов производить по http-протоколу. На этом этапе приложение уже должно работать как самостоятельный и независимый сервис (базируясь на стандартном варианте tclhttpd). Разобравшись детальней в объектно-ориентированном программировании перейти к углубленному изучению пакета tclhttpd и заняться его переделкой.
12 марта 2009 в 4:05
И только после реализации своей редакции tclhttpd приступить к реализации ftp-сервера и связыванию его с основным движком.
На данный момент мой движок выступает в роли обычного http-сервера, умеет выдавать результат выполнения скриптов, выдавать файлы с файловой системы, различать get/post-запросы; принимать и сохранять файлы, переданные через get/post-запроссы.
Каталог “/lm“ сервера обслуживается встроенными процедурами, которые начинаются с приставки “html/”. Т.е. документ, доступный по адрессу “//localhost/lm/index.htm” является результатом работы процедуры “http/index.htm”, индексный документ папки “//localhost/lm/test/” является результатом, возвращенным процедурой “http/test/”, а документ “//localhost/lm/test” – результатом процедуры “http/test”. Т.е. все просто и понятно. Также сервер понимает аргументы get-запросов, которые в процедуру передаются как список пар “название переменной/значение”. Т.е. запрос “//localhost/lm/test?a=1&b=2” заставит выполниться процедуру “http/test”, входные параметры которой будут содержать текст “a 1 b 2”, который можно трактовать как строку текста. Запрос “//localhost/lm/test?a=сервер библиотеки&b=2” заставит выполниться процедуру “http/test”, входные параметры которой будут содержать текст “a {сервер библиотеки} b 2”. Т.е. имена параметров и их значения в любом случае разделяются пробелами, а текст внутри скобок трактуется самим tcl-интерпретатором как единое значение, будь-то значение параметра, или имя самого параметра. Надеюсь, вы уже и сами понимаете что все довольно просто.
Сейчас занимаюсь разработкой структуры сайта. Параллельно происходит разработка процедур работы с базами данных – необходимо унифицировать процедуры работы с sqlite3 и mysql. Далее начнется разработка структуры базы данных.
Необходима помощь умеющих разрабатывать сайты. Вся завязка на HTTP+CSS с небольшой долей JavaS?1?ript. Реализовать сайт при таких требованиях – дело сравнительно простое, но у меня мало опыта в реализации именно структуры сайта, а не его отдельных компонентов.
К стати: литературы по веб-разработке полно, дадут, да еще и добавят, но мне еще не встречалась ни одна путевая книга, в которой доступно был бы описан момент проектирования структуры будущего сайта. Все автора почему-то считают, что читатель уже разработал структуру своего сайта и после маленького введения сразу же переходят к описанию азов html-верстки. Буду благодарен за предоставленную информацию о путевой литературе по проектированию структуры сайтов.
12 марта 2009 в 4:04
Итак, немного о процессе продвижения. Пишу то, что считаю необходимым.
Название, редакция 1: библиотека электронных документов.
Слово "библиотека" выбрано в связи с тем, что сервис должен предоставлять доступ не только к каталогу файлов, но и к самим файлам. Без предоставления файлов сервис смело мог называться "каталогом."
Слова "электронных документов", а не "электронных файлов", именно потому, что база предназначена для хранения любых пользовательских документов в электронном виде. Словосочетания "электронный файл" и "электронный документ" в моем понимании имею разную смысловую нагрузку. Если "электронный файл" означает просто совокупность бит информации (бессмысленная инфа никому не нужна), то выражение "электронный документ" вызывает любопытство по поводу наличия таких важных атрибутов как: название, автор, аудитория возcтребованости и т.д. Т.е. "документ" имеет более близкую человеку смысловую нагрузку, и более конкретную, нежели понятие "файл".
Размышления привели к необходимости разделения на следующие логические части:
1) движок приложения;
2) движок работы с базой данных каталога;
3) движок работы с файлами каталога;
4) движок взаимодействия с пользователями;
5) движок взаимодействия с себе подобными библиотеками.
1) ДВИЖОК ПРИЛОЖЕНИЯ.
Это основа приложения. Движок, собственно, пишется полностью на Tcl. Вроде и так ясно.
2) ДВИЖОК РАБОТЫ С БАЗОЙ ДАННЫХ КАТАЛОГА.
База данных хранит список всех документов и их атрибутов.
После некоторых раздумий в качестве базы данных решено использовать на выбор sqlite3 или mysql.
Наличие выбора было сделано намеренно: MySQL – для сетевых реализаций, sqlite3 – для тех, кто в танке. Эти базы данных общедоступны, широко разпостранены, многими изучены, имеют продвинутую функциональность, удовлетворительную производительность и являются OpenSource. К тому же пакеты расширения для доступа к этим базам данных существуют для Tcl. Пакеты расширения в виде динамических библиотек, поэтому не предоставляют мне простора для экспериментов, но этого от них и не требуется, так как эти пакеты необходимы лишь в качестве моста к "складу" информации. Этого нам и надо.
3) ДВИЖОК РАБОТЫ С ФАЙЛАМИ КАТАЛОГА.
Каталог, собственно, существует именно для классификации обслуживаемых документов. А полезной информацией являются именно электронные документы. В компьютере они представляются в виде файлов. Следовательно, необходимо научить программу работать с этими файлами. Можно было бы хранить и файлы в самой базе данных вместе с каталогом, но такой сценарий имеет множество недостатков, учитывая которые отказываюсь от подобной затеи. Файлы должны где-то храниться, как-то загружаться в базу и выдаваться из базы. Решено за пределы возможностей веб-браузера не выходить.
Загрузку файлов в библиотеку можно реализовать посредством передачи файла прямо из веб-формы клиентов, выполненной на простом html. Т.е. это реализовано в самом http протоколе, который вполне подходит и для загрузки файлов в библиотеку. Но согласно информации, которой владею, этот протокол имеет недостатки, основным из которых является плохая ориентированность на работу c файлами больших размеров. Удельная масса запросов клиентов при работе с библиотекой направлена на работу именно с каталогом, а не с содержимым библиотеки, для работы с которым существует много более эффективных инструментов. Первая встречная мысля указала на ftp протокол, широко разпостраненный и не требующий почти никаких знаний для владеющих опытом работы в интернете. Есть одно НО – нынче разпостраненные браузеры умеют только читать информацию по этому протоколу, т.е. смогут только прочитать файлы из базы, но не загрузить в нее. Учитывая что библиотека в основном будет выдавать документы, можно смириться с недостатками http при загрузке файлов на сервер. А для выдачи документов сервером вполне подходит ftp. Пакет расширения для Tcl реализован в виде текстового кода и вмещается в 60кб, разобратьс
12 марта 2009 в 0:05
>лучше хранить информацию для генерации страниц в том же mysql – вдруг захочется изменить дизайн?
Согласен, преимущества налицо. Существует одно НО. Минимизация кода, проходящего через движок значительно повысит безопасность приложения. Второй причиной отказа от такой затеи является желание сделать рабочую программу, а не рабочую программу с максимумом наворотов. Обсуждение вопросов динамической смены стиля интерфейса планирую после выхода нескольких версий, стабильных и готовых для массового распостранения.
> почему Tcl?
> ты уверен что велосипед не изобретаешь?
Tcl – язык скриптовый, расширяемый, можно дописать все, чего не хватает. Начинающий напишет что-либо только после того, как прочувствует свой код. Велосипед? За основу беру пакет расширения tclhttpd, применение которого преврящяет интерпретатор в полноценный http-сервер, код которого влазит в 400 кб (весь код, реально используются около 150кб). Так что только изменяю уже существующее. А опыт исследования протоколов http и ftp откроет мне новые знания и возможности…
21 февраля 2009 в 1:01
а что страшного в том, чтобы изобрести велосипед? какой-никакой опыт.
20 февраля 2009 в 1:03
почему Tcl?
ты уверен что велосипед не изобретаешь?
19 февраля 2009 в 22:05
лучше хранить информацию для генерации страниц в том же mysql – вдруг захочется изменить дизайн?