Loading...
Error

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

Страницы:  1, 2, 3, 4, 5, 6, 7, 8  След.

Ответить на тему

 | 

 
Автор Сообщение

Bill_G

KaraBY

Цитата:

Для пакетной загрузки необходимо сформировать / сгенерировать уникальное имя издания, которое будет фигурировать в имени файла (наряду с годом и номером).
Возможны два (?) варианта - абстрактный числовой ID или осмысленное (относительно) имя.
Минус 1-го варианта - легко ошибиться, если переносить номер вручную.
Минус 2-го варианта - при переименовании издания нужно либо менять имя либо имя не будет соответствовать названию. + вероятность (значительно >0) одинаковых имен (особенно для газет)
Bill_G

Цитата:

я за 2 вариант,
поскольку 1 вариант только увеличит хаос, ввод доп. ИД (в именах файла) не связанных с библиографией создаст доп. проблемы.

Минус 2-го варианта - при переименовании издания нужно либо менять имя - так и в 1 варианте тоже придется переименовывать, только тут нам придется привести уже осмысленно поименованные журналы к одному формату имени, а в 1 случае переименовывать с нуля каким-то левым ID

вероятность (значительно >0) одинаковых имен (особенно для газет) - откуда же взятся одинаковому имени?
если у нас формируется таблица, на основе ее - список как должны быть поименованы файлы в папке на фтп, то одинаковых имен не должно быть в принципе,
тут другая проблема - если 1 номер представлен в 2-х вариантах, с одинаковым расширением (предполагается, что одинаковые имена с разными расшиениями будут восприняты скриптом как 2 версии одного номера)- тут надо решить вопрос как именовать такие файлы, и как должен работать скрипт, который воспринимал бы подобный вид имени,
например
Химия и жизнь 2007-05[1].djvu
Химия и жизнь 2007-05[2].djvu

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

KaraBY

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

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

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

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

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

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

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

Bill_G

Цитата:

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

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

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

PS http://bibliography.ufacom.ru/library не работает.....

Цитата:

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

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

KaraBY

Bill_G писал(а):

Цитата:

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

Цитата:

а если добавляется новый номер новый файл придется составлять?
Или сгенерировать новый шаблон или подправить старый.

Цитата:

PS http://bibliography.ufacom.ru/library не работает.....
Да, я обновил версию PHP, но она пока не принялась apache, поэтому apache не запустился. Занимаюсь.

Цитата:

Цитата:

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

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

KaraBY

KaraBY писал(а):

Bill_G писал(а):

Цитата:

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

Цитата:

а если добавляется новый номер новый файл придется составлять?
Или сгенерировать новый шаблон или внести изменения в старый. Но если добавляются отдельные номера, то нет смысла использовать пакетную загрузку, Может будет проще загрузить по одному? Сейчас я делаю как раз загрузку отдельных номеров (как с передачей на сервер, так и без передачи)

Цитата:

PS http://bibliography.ufacom.ru/library не работает.....
Да, я обновил версию PHP, но она пока не принялась apache, поэтому apache не запустился. Занимаюсь.

Цитата:

Цитата:

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

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

Bill_G

Цитата:

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

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

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

KaraBY

Bill_G писал(а):

Цитата:

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

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

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

Bill_G

Цитата:

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

KaraBY

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

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

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

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

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

Bill_G

Цитата:

Параметр "а" создается сервером
- да,
только я не согласен, что это должен быть 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 найден, то с этого файла берется и размер и хеш и еще какие надо параметры

KaraBY

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

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

2.

Цитата:

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

Bill_G

Цитата:

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

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

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

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

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

Цитата:

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

Цитата:

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

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

KaraBY

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

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 обязательно должен быть открыт анонимный доступ (это так, к сведению)

Bill_G

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

Цитата:

3. Загружается файл
куда?

Bill_G

Цитата:

- в какой кодировке они будут в пакетном файле - если win1251, то мы имеем проблемы с расширенной латиницей
расширенной латиницы в именах файлов не будет, а вот кириллица будет,
пробовал загрузить в кодировке 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

Цитата:

номер - так как создано в раскладке номеров
какой именно?
номер месяца в году, Текущая (погодная) нумерация, Валовая (сплошная) нумерация ?
Показать сообщения:    
Ответить на тему