Re: Re: [Gaim-commits] CVS: gaim/src gtkconv.c,1.504,1.505

On Wed, 15 Dec 2004 22:43:14 -0600, Tim Ringenbach <omarvo@xxxxxxxxxxx> wrote:
> Felipe Contreras wrote:
> 
> >Indeed, I would like something like that.
> >
> >Maybe inside .gaim/icons we can have a folder for each one of the
> >protocols, and then inside that, each file named as it's hash.
> >
> >
> I'd rather keep all the files in the same directory. Name them all after
> their hash,
> have an index file which lists all the files and several hashes for each
> of them for the
> protocols different hashing. On Gaim it's probably going to be common to
> have
> a buddy on several protocols, who's likely to set them all to the same icon.

That looks very elegant to me (having a cacheable object mapped even
through different protocols). But I don't see a huge real advantage,
anyway buddy icons are scaled and their hash will be different.

So I still vote for a protocol directory, mostly because of the easier
implementation, but whatever is fine for me.

> >Also considering the custom smileys maybe the folder can be named as
> >.gaim/cache and there the prpl can store whatever files it caches.
> >Maybe each prpl can have a different directory structure inside its
> >cache dir or something.
> >
> I'd just assume keep the old folder name and keep them both together,
> unless there's some advantage to keeping them seperate.
> I figure the files can be named after their md5 hash or something, and
> an index file stores other hashes for them, perhaps in a protocol
> specific way. And it stores other metadata like last accessed from gaim.

The advantage to have a .gaim/cache is that it's more descriptive (if
we are going to add smileys)

The advantage to have a .gaim/cache/{icons,smileys} is that if we want
to see the buddy icons we have chaced, or the custom smileys, well,
you pretty well know where to find them.

But then again what I'm talking about is:

.gaim/cache/{msn,yahoo,jabber,...}/{icons,smileys}

> The tricky part is how protocols hold references on them (if at all),
> how you avoid stale references from leaving files around forever, and
> when you delete them. I'm thinking the simplest way is just "hasn't been
> used in x days". But perhaps metabytes and number of files should play a
> role. I don't really know, i've never coded something like this, someone
> who's worked on e.g. mozilla might know better.

Ok, again I think that's an elegant solution, but the bulk of the mess
comes from duplicated buddy icons, that should be the most important
thing to fix, and again, whatever is fine for me.

-- 
Felipe Contreras


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/