Пакетная загрузка - формирование уникального имени издания

KaraBY Bill_G

Продолжаем про пакетную загрузку, ибо я как раз до этого дошел на практике.

Если мы под пакетной загрузкой понимаем только передачу информации о файле без реальной пересылки файлов, то необходимо следующее:

От пользователя на сервер передается некий файл типа торрент-файла с необходимой информацией.

Я предлагаю использовать xml-формат и некую утилитку (которая будет написана в версиях для Windows и Unix) для создания этого файла.

Содержание (структура) файла:

1. ключ для идентификации номера журнала в базе данных. Как мы определились выше, это будет: "уникальное имя издания"+"год издания"+"физический номер". Как альтернатива (или дополнение?) это может быть уникальный ID номера (сгенеренный в базе данных по предыдущим 3-м параметрам). Ключ создается на стороне сервера и пересылается пользователю по его запросу.

2. Описание файла журнала - создается пользователем с помощьювышеуказанной "некой" утилитки: сюда войдет:
а)имя файла
б)путь к файлу в виде URL - только http:// или ftp:// (?)
в) формат файла (мне всё же кажется это должен быть предопределенный, хотя и расширяемый список)
г) размер файла в байтах
д) md5 файла - в heх нотации
е) заметки, комментарий пользователя к именно этому файлу (оценка качества, разрешение, дефекты и т.п.)

мы же решили, что сервер сам генерирует как должны выглядеть имена файлов на основе таблицы,

тут же мы делаем двойную работу, - составляем таблицу+ пишем еще некий файл типа торрент-файла, а если добавляется новый номер новый файл придется составлять?

в таком усложнении есть реальная техническая необходимость?

PS http://bibliography.ufacom.ru/library не работает..... думаю, что тут необходим только путь до файла, который должен быть уникален, все остальное может досчитываться и заносится в базу скиптом позже,

например у Library genesis есть программа libgenhach ( http://spacelib.narod.ru/news.html ), она считает доп. хеши к файлам, ей указывается база данных, где прописаны пути к файлам на диске,и с какого ID файла начинать считать, она считает хеши, и одновременно пишет их в базу, считаю, что таким же образом должна быть решена и наша задача с размерами файлов\хешем\обложками

Да, я не совсем внятно и не совсем последовательно описал. Думать приходится на ходу : Моё предложение (на обсуждение): 1. на сервере мы выбираем (жмем кнопку) "создать шаблон для пакетной загрузки". Варианты: а) выбираем конкретные номера или годы, б) выбираем всё издание 2. Нам на скачку генерится файл-заготовка (тот же XML), в котором заполнены только 1-я часть (см. выше) из 2-х 3. Шаблон на стороне клиента (пользователя) подсовывается утилитке или правится вручную текстовым редактором (ибо XML), где заполняется 2-я часть. 4. Заполненный файл отсылается на сервер, где информация заносится в базу и готова к употреблению. Или сгенерировать новый шаблон или подправить старый. Да, я обновил версию PHP, но она пока не принялась apache, поэтому apache не запустился. Занимаюсь. Дело в том, что мы же решили, что по умолчанию сами файлы остаются у "клиента" и не передаются на сервер (в случае пакетной заливки). Поэтому откуда сервер узнает всю необходимую информацию - путь, размер, md5 и т.д.?

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

например загрузчик для либгена: http://free-books.dontexist.com/librarian/

там не надо никуда писать хеш\размер\расширение, они извлекаются скриптом на стадии загрузки файла на сервер

Ключевая фраза - "когда файлы будут на сервере". Когда мы заливаем файлы на сервер (на котором и стоит наша система), то проблем нет - см. в тестовой версии - 1-й вариант загрузки - указываешь имя файла на своем клиенте и жмешь "загрузить". Всё. Речь идет о 2-м и 3-м вариантах "загрузки", когда файлы в действительности никуда не пересылаются, а остаются у "клиента", в базу же заносится только информация о них. Откуда же сервер её возьмёт? Мы же как бы решили разделить (логически - точно, физически - м.б. частично) сам веб-интерфейс системы ("сервер") и репозитории. При этом нет никакой необходимости гонять терабайты файлов между репозиториями и сервером. Нужно только обменяться информацией где что есть.

вот именно, при пакетной загрузке не надо указывать имя файла, сервер уже сам заранее знает как каждый конкретный номер должен называться и где лежать (на основе составленной табл.), соответственно знает по какому адресу обращаться в репозиторий, и от какого файла брать информацию, в таком случае наличие клиентской программы не нужно

Так, еще раз. Может мы об одном и тоже но по разному говорим и поэтому друг-друга не понимаем...

1. Нам надо на сервере заполнить таблицу базы данных: а) ID номера, сгенерированнный при создании раскладки (уникальная связь с параметрами: издание/год/номер) б) путь, где лежит файл - URL внешнего репозитория (напр. ftp://free-books.dontexist.com/folder1/magazine22/) или адрес "внутреннего" хранилища, если файл нам залили напрямую (напр. /var/library/ul) в) имя самого файла (может быть разным на разных хранилищах!) г) размер д) md5 е) формат ж) описание файла ("заметки, комментарий", вроде должно быть одно?) Пока разногласий нет?

2. Как эту таблицу заполнить? Предлагается три варианта: 2.1. Непосредственная заливка одиночных файлов на сервер в его хранилище. Здесь вся информация берется непосредственно из файла и (описание) - из веб формы при загрузке.

2.2. Загрузка информации об одиночном файле без заливки самого файла - мы заполняем формочку на сервере с ручным вводом всех параметров (б,в,г,д,е,ж)

2.3. Пакетная загрузка информации (без заливки самих файлов). Вот тут, как я понял, у нас недопонимание? Как мы должны заполнить параметры (те же "б"-"ж")? Параметр "а" создается сервером, но б-ж должны заполниться клиентом на основе информации в репозитории. Может проиграть всё на каком то примере?

- да, только я не согласен, что это должен быть ID, ID -это не основной параметр, а вспомогательный, основным должен быть путь к файлу в репозитории, но почему сервер не может запросить файл по указанному в параметре а) URL и забрать у указанного файла требуемые параметры, для чего нужно промежуточное звено в виде программы-клиента? конечно, например: http://62.133.161.13/library/j/20 при создании таблицы, мы указываем, что все файлы лежат например в: ftp://free-books.dontexist.com/magz/%D0%B6%D1%83%D1...%B8%D0%BA%D0%B0/

сформировали записи за 2003 год, сервер ждет от нас

имен файлов типа: Популярная механика 2003-01.ext Популярная механика 2003-02.ext Популярная механика 2003-03.ext Популярная механика 2003-04.ext Популярная механика 2003-05.ext Популярная механика 2003-06.ext Популярная механика 2003-07.ext Популярная механика 2004-08.ext Популярная механика 2003-09.ext Популярная механика 2003-10.ext Популярная механика 2003-11.ext Популярная механика 2003-12.ext

к этим именам прибавляется ранее введенный путь к подшивке на фтп,

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

Приступив к отработке технологии пакетной загрузки всплыли как положительные так и не совсем моменты:

1. по п. а) для идентификации номера достаточно года и номера - можно опустить идентификацию самого издания (если мы закладываем, что в одном пакетном файле только одно издание) и соотв. не париться с ID. Только нужно определиться - как указываем номер - особенно если это сдвоенный. Имеются два "варианта" - 1-й по "физическому номеру", как он был сгенерирован при создании раскладки и потом привязан к реальному номеру (т.е. напр. для сдвоенного номера "4-5" физ. номер м.б. "4"), 2-й - по "реальному номеру", так как он прописан в базе (напр. "4-5")

2. "Сканировать" можно автоматом при загрузке пакетного файла. Проблема в том, что таким образом можно только получить размер файла, но не md5!!! Хэш должен либо храниться где-то на самом фтп либо нужно скачивать файл и считать (чего мы позволить себе пока не можем).

по реальному - то есть 4-5 в противном случае очень высока вероятность путаницы

думаю, что формата Название Год(4 цифры)-номер за год(2 цифры вполне достаточно) напр. имен файлов типа: Популярная механика 2003-01 Популярная механика 2003-02-05

по поводу сканирования хочу дополнить свой предыдущий пост, с примером журнала,

неплохо бы сканировать содержимое папки по маске имен файлов типа: Популярная механика 2003-01*.* Популярная механика 2003-02*.* Популярная механика 2003-03*.*

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

а может в таком случае отказаться от хеша? и вести сравнение только по размеру файла, но не по всей базе, а только по папке с конкретной подшивкой (размер файла ~5-100 мбайт, в подшивке в среднем 100 номеров, т.е. 100 000 000 \100 | 5000000\100 вероятность того, что попадутся разные номера с одинаковым размером в одной подшивке колеблется от 50000 до 1000 000 к 1, может такой точности нам достаточно?)

Тестовая версия пакетной загрузки:

1. Создается файл следующей структуры:
- один файл - один журнал (т.е. в одном файле только один журнал, но файлов может быть сколько угодно)
- одна строка - один номер журнала
- строка: "url|год|номер|описание|MD5", где url - полный путь ftp или http; год, номер - так как создано в раскладке номеров; описание (необязат.) - комментарии; MD5 - необязат., но желат.
пример:
ftp://free-books.dontexist.com/comics1/!Ablaze Media/Tozzer 2 (Ablaze Media)/Tozzer 2 05 (2005) (Team-DCP).cbr|2005|2

2. На странице журнала пункт "Залить много" (внизу).
3. Загружается файл
4. На экране - "протокол" загрузки. Пока без реальной записи в базу данных.

Проблемы - те, что уже обсуждались:
русские имена файлов, а именно
- в какой кодировке они будут в пакетном файле - если win1251, то мы имеем проблемы с расширенной латиницей, если utf-8 (или ucs-2), то некоторые редакторы вставляют (а некоторые не вставляют!) в начале файла спец. признак (2 байта)
- реакция на русские имена различна у протоколов ftp и http (и внутри одного протокола тоже!)

И еще - при размещении файлов на ftp обязательно должен быть открыт анонимный доступ (это так, к сведению)

пишет файл не найден http://magzdb.org/ptools/bul/j/20 кодировка была UTF8 куда?

расширенной латиницы в именах файлов не будет, а вот кириллица будет, пробовал загрузить в кодировке win1251 не может найти URL

транслителировал, файл скушало

ftp://free-books.dontexist.com/magz/magz/Populyarnaya mehanika/Populyarnaya mehanika 04 2003-02 HQ.cbr: Файл найден. Размер - 73351857 ftp://free-books.dontexist.com/magz/magz/Populyarnaya mehanika/Populyarnaya mehanika 05 2003-03 HQ.cbr: Файл найден. Размер - 72933144

но а что же дальше?

PS я все таки не понимаю, какая информация содержится в пакетном файле, которую сайт не может взять сам из листинга файлов на фтп, при условии именования номеров журнала по шаблону PPS какой именно? номер месяца в году, Текущая (погодная) нумерация, Валовая (сплошная) нумерация ?