Задача: реализация кэша для быстрой подгрузки.

Описание задачи:
Есть И-нет, из которого берутся пикчи. Пикч очень много (под 1кк и более, но их размер не большой, 5-10кб. Естественно качаться одновременно буду не все, но под тысячу-другую вполне вероятно). Изначально мы имеем только урл этих пикч (ресурсы разные, имена файлов могут совпадать).
Надо хранить пикчи на винте (вариант "пофайлово" возможен, но скорость работы подобного кеша (вспоминаем печально известного осла ака internet explorer) совсем не впечатляет, кроме того МУСОР, поэтому рекомендуется "однофайловая" реализация). То ли по url, то ли по заголовку http файла (или все вместе) надо опознавать наличие кэша, но случайное совпадение не допустимо.

В последствии этот кэш должен динамически подгружаться в память (напр. в timage`ы) и выгружаться из нее (напр. когда timage уже будет не виден), но это уже совсем другая история.

Гугл сказал мне, что дельфи и кэширование подобного характера - не очень популярная идея, поэтому прежде, чем я начну изобретать велосипед, хотел попросить совета у местных, вдруг кто-то уже делал что-то подобное и может что-то посоветовать по основным пунктам. Может даже уже есть компонент, который делает похожую задачу, но <s>я дурак и был пьян</s>.

Дикая сумбурность изложения - как головой в навоз.
Может Вам просто базу данных потрогать ?

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

Вариант хороший, тогда надо будет начать с поиска бездрайверного, безбиблиотечного, безсерверного БД, что-то вроде TDBF с доприкрученной поддержкой BLOB полей.

С тем же успехом можно взять TFileStream и последовательно писать заголовок (уникальное идентификационное имя), размер и тело. В TList хранить список структур "имя":"адрес на файл":"размер" для упрощенного поиска.

В качестве уникального идентификатора брать запакованную строку полного url пика, или кодировать в md5. Искать по этому идентификатору и размеру.

В теории подход будет удачен. Но делая что-то в первый раз, всегда было бы не плохо ознакомиться с опытом других в данном вопросе.

> Вариант хороший, тогда надо будет начать с поиска бездрайверного,
>  безбиблиотечного, безсерверного БД


Ерунда. "Без-серверных" СУБД пруд-пруди.
Тот же FB, к примеру.

Опыт есть такой, к примеру:

Продукт SAS-planet оперирует кешем: десятки гигабайт изображений в виде тайлов 256*256 (число файлов исчисляется сотнями тысяч). Изначально все делалось на файловой системе, но потом были удачные переводы на однофайловую БД.

Использование СУБД вроде FB и подобных ему для таких целей (конкретнее ТОЛЬКО для этой цели) выглядит как использование микроскопа для забивания гвоздей. Решение, конечно, простое, но отнюдь не изящное... Не считая все тех же драйверов и библиотек. Конкретно в моем случае все необходимое для работы БД Firebird в локальном файловом режиме будет занимать больше места, чем моя программа, и это лишь для того, чтобы сделать кэширование картинок.

> Конкретно в моем случае все необходимое для работы БД Firebird


Твои проблемы.
Там всего-то одна dll в 1.5 Mb.

Если не знаете наверняка и нет желания проверять, то лучше не пишите

>Для использования Embedded Firebird в приложении выполните следующие шаги:
>Скопируйте библиотеку fbembedded.dll в папку с приложением.
>Переименуйте библиотеку в fbclient.dll или в gds32.dll, для того чтобы ваше приложение смогло обнаружить клиентскую часть Firebird Embedded
>Некоторые старые приложеняи ищут клиента gds32.dll, в то время как утилиты командной строки isql, gbak и т.п используют fbclient. Вы можете сделать 2 копии: gds32.dll и fbclient.dll.
>Скопируйте firebird.msg и ib_util.dll в папку с программой.
>Скопируйте aliases.conf – это позволит использовать псевдонимы путей к БД при подключении
>Если необходимо изменить root директорию скопируйте firebird.conf
>Для Firebird 2 и выше скопируйте все файлы по маске icu*.dll.
>Скопируйте содержимое папок udf и intl.

aliases.conf 1kb
fbembed.dll 3696 kb
firebird.conf 17kb
firebird.msg 146 kb
ib_util.dll 8 kb
icudt30.dll 1532 kb
icuin30.dll 408 kb
icuuc30.dll 660 kb
intl\fbintl.conf 7 kb
intl\fbintl.dll 900kb
udf\* 70 kb

итого всего лишь 7,3 мб для работы программы 2,5 мб.

Ну возьми тот же TClientDataSet

> Там всего-то одна dll в 1.5 Mb.


Я имел в виду для FB 1.5 без udf и утилит всяких (т.е. минимальный состав), которые в Вашем случае не нужны..
Конфиги нужны, да, по размеру не принципиальны - ну так Вы и разобрались.

17.04.2003  12:54         1 421 312 fbembed.dll
14.04.2003  21:57            16 377 firebird.conf
13.04.2003  17:01           131 836 firebird.msg

Посмотри на handycahce. Нормально вроде бы кэширует пофайлово, опять же, потом можно посмотреть. Из базы их не очень-то посмотришь. Если в будущем понадобиться хранение страниц (как показывает практика, задачи имеют свойство разрастаться со временем), то пофайлово будет проще вирусы потом искать.
Я бы взял готовый hc, тем более, что он бесплатный (правда, не во всех случаях) и не заморачивался со своей реализацией.

> Посмотри на handycahce

Действительно очень полезная софтинка, возможно действительно не следует заморачиваться с ручной реализацией. Спасибо за ссылку.