По своему опыту могу сказать, что при написании статьи некоторые картинки вставляются, но потом меняются на другие.
Поэтому предлагаю картинки не заливать сразу, а хранить локально информацию о них. При редактировании вставлять в текст метки, которые в препросмотре расширением заменяются на картинки. Также есть кнопка «готово к публикации» (например) по нажатию которой изображения, участвующие в статье, заливаются уже на сторадж, и метки заменяются нормальными тегами.
Плюс в том, что на сервер не заливаются «мертвые» изображения, которые нигде потом не участвуют. Минус, очевидно, в переносимости черновика между компьютерами.
Первый фактор повлиял на выбор в сторону разработки основной части приложения на HTML5 — иначе малейшее изменение алгоритма входа в личный кабинет приводило бы к неработающему в течение недели приложению.
Как я вижу с высоты своего понимания специфики таких систем, проблема решается собственным API, внутренности которого меняются по мере изменения логики работы ЛК, что не требует обновления самого приложения. На HTML все очень долго работает, да и если интернета нет, а статистику посмотреть хочется… Или я не прав?
The operating system arrives as the golden master build 10A403 for existing devices, and Apple has also posted a special 10A405 build for the iPhone 5 and a 10A406 build for the upcoming fifth-generation iPod touch.
Хардлинк не меньшее неудобство, а нормальное решение. Надоело раздавать — удали раздачу. Надоело слушать/смотреть/читать — удали коллекцию. При таком подходе не надо думать, что удалив одно похеришь другое.
Когда ползали по трекеру. Нашли две раздачи. Скачали их .torrent-файлы. Закинули их (.torrent-файлы) в клиент, который вытянул раздачи. Каждую в свою папку. Мы, по завершению загрузки, эти две папки взяли и отсортировали как нам надо. НО. У нас в первой раздаче был файл, который есть и в другой (получилось после скачивания два одинаковых файла в разных папках). Мы это спалили и при сортировке один из них удалили.
Это предыстория. Теперь мы хотим вернуться на раздачу. Запускаем программу, речь о которой в статье. Она читает эти два .torrent-файла в папке, которую мы ей скормили. И копирует файл дважды — для первого и для второго прочитанных .torrent-файлов.
Получилось дублирование файлов, что нам очень не нравится — места много не бывает. Тут как раз на помощь приходит механизм хардлинков.
Если данные сдвинуты на байт, то ни один хеш уже не совпадет. В этом и проблема, из-за которой я пока не хочу использовать этот «порог». Сейчас хочу сделать проверку всего файла, но при первом несовпадении считать «не тем» и поиск продолжать дальше.
Нашли два .torrent-файла, в которых есть один одинаковый файл. Мы их скачали, отсортировали для удобства пользования, и у нас на диске остался только один файл (ну в коллекции книг, например, нет смысла держать две одинаковых). И тут мы захотели вернуться на ОБЕ раздачи. Мы, немного изменив код программы, вернули все как было и получили, что файлов одинаковых снова два, и они оба занимают место.
И вот тут-то хороша система хардлинков.
А про поиск двух одинаковых файлов в .torrent — не такая большая проблема, если немного изучить строение фалов и переосмыслить статью в контексеt поиска не файлов на диске, а описания файлов в другом файле.
Сейчас проверяется только первый кусок, и, если его хеш совпадает, то он считается нашим. Можно проверять все куски, которые есть в этом файле (это есть, отлажу и запилю), но тут возникает вопрос, как считать правильность? Можно считать подходящим только тот файл, у которого совпал хеш всех проверенных кусков. А можно выставить «порог доверия», то есть говорить, что файл наш, если совпали, скажем, 75% кусков, независимо от их положения в файле.
Размер поменяется, а вот раздавать все равно можно будет, но только те части файлов в которых находится непоследственно музыка. Те части, в которых находятся теги, будут, естественно, признаны негодными для раздавания.
Скорее всего имеется в виду такая ситуация: есть два .torrent-файла раздач, в которых присутствует один или несколько одинаковых файлов. Если мы будем копировать найденные на диске файлы, то получится как раз избыточность данных на диске. Это можно решить с помощью хардлинков.
Поэтому предлагаю картинки не заливать сразу, а хранить локально информацию о них. При редактировании вставлять в текст метки, которые в препросмотре расширением заменяются на картинки. Также есть кнопка «готово к публикации» (например) по нажатию которой изображения, участвующие в статье, заливаются уже на сторадж, и метки заменяются нормальными тегами.
Плюс в том, что на сервер не заливаются «мертвые» изображения, которые нигде потом не участвуют. Минус, очевидно, в переносимости черновика между компьютерами.
Как я вижу с высоты своего понимания специфики таких систем, проблема решается собственным API, внутренности которого меняются по мере изменения логики работы ЛК, что не требует обновления самого приложения. На HTML все очень долго работает, да и если интернета нет, а статистику посмотреть хочется… Или я не прав?
А когда Passbook будут и будут ли вообще?
Это предыстория. Теперь мы хотим вернуться на раздачу. Запускаем программу, речь о которой в статье. Она читает эти два .torrent-файла в папке, которую мы ей скормили. И копирует файл дважды — для первого и для второго прочитанных .torrent-файлов.
Получилось дублирование файлов, что нам очень не нравится — места много не бывает. Тут как раз на помощь приходит механизм хардлинков.
Так понятней?
Нашли два .torrent-файла, в которых есть один одинаковый файл. Мы их скачали, отсортировали для удобства пользования, и у нас на диске остался только один файл (ну в коллекции книг, например, нет смысла держать две одинаковых). И тут мы захотели вернуться на ОБЕ раздачи. Мы, немного изменив код программы, вернули все как было и получили, что файлов одинаковых снова два, и они оба занимают место.
И вот тут-то хороша система хардлинков.
А про поиск двух одинаковых файлов в .torrent — не такая большая проблема, если немного изучить строение фалов и переосмыслить статью в контексеt поиска не файлов на диске, а описания файлов в другом файле.