From: Luke S. <lsc...@us...> - 2004-12-15 20:48:05
|
one side effect of writting these files to ~/.gaim/icons was that we could display htem the next run time without having to download them again. luke On Wed, Dec 15, 2004 at 12:34:11PM -0800, Tim Ringenbach wrote: > Update of /cvsroot/gaim/gaim/src > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24381/src > > Modified Files: > gtkconv.c > Log Message: > Gabor Farkas wanted to hack his blist.xml file so he could set buddy icons > for jabber buddies, who's screenname's have slashes in them. While I don't > recommend this, his patch, which changes how we load buddy icons in > conversations to not write tmp files, is good nevertheless. > |
From: Kevin M S. <ke...@si...> - 2004-12-15 20:56:44
|
Luke Schierer wrote: > one side effect of writting these files to ~/.gaim/icons was that we > could display htem the next run time without having to download them > again. > > luke > > On Wed, Dec 15, 2004 at 12:34:11PM -0800, Tim Ringenbach wrote: > >>Update of /cvsroot/gaim/gaim/src >>In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24381/src >> >>Modified Files: >> gtkconv.c >>Log Message: >>Gabor Farkas wanted to hack his blist.xml file so he could set buddy icons >>for jabber buddies, who's screenname's have slashes in them. While I don't >>recommend this, his patch, which changes how we load buddy icons in >>conversations to not write tmp files, is good nevertheless. >> I don't think this affects buddy icon caching. This has to do with a temporary file we created for the reported reason that there was a leak we needed to work around. Making that hackiness go away should be unarguably good, unless the leak is still there and significant. Kevin |
From: Tim R. <om...@ho...> - 2004-12-16 04:43:45
|
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. >I don't know how does each prpl does buddy icons, but I think each one >of them uses some kind of hash, at least if it does some kind of >caching. > Yahoo uses some kind of 32bit number. We never did figure out how they generated it, we generate it ourselves using g_string_hash, so our value for a given icon doesn't match yahoo's, but in practice that doesn't matter, since it's usually only used to see if the new icon is different from the old one. People in charge of other protocols feel free to describe what their protocol uses. >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 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. --Tim |
From: Felipe C. <fel...@gm...> - 2004-12-22 09:17:15
|
On Wed, 15 Dec 2004 22:43:14 -0600, Tim Ringenbach <om...@ho...> 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 |
From: Evan S. <ev...@dr...> - 2004-12-15 23:47:33
|
What exactly does the cache in ~/.gaim/icons do? I currently have 56.6 MB of files in there (8,435 files, significantly more buddies than I have on my list). -Evan On Dec 15, 2004, at 2:47 PM, Luke Schierer wrote: > one side effect of writting these files to ~/.gaim/icons was that we > could display htem the next run time without having to download them > again. > > luke > > On Wed, Dec 15, 2004 at 12:34:11PM -0800, Tim Ringenbach wrote: >> Update of /cvsroot/gaim/gaim/src >> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24381/src >> >> Modified Files: >> gtkconv.c >> Log Message: >> Gabor Farkas wanted to hack his blist.xml file so he could set buddy >> icons >> for jabber buddies, who's screenname's have slashes in them. While I >> don't >> recommend this, his patch, which changes how we load buddy icons in >> conversations to not write tmp files, is good nevertheless. >> > > > ------------------------------------------------------- > 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/ > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel > |
From: Tim R. <om...@ho...> - 2004-12-15 23:58:04
|
Evan Schoenberg wrote: > What exactly does the cache in ~/.gaim/icons do? I currently have > 56.6 MB of files in there (8,435 files, significantly more buddies > than I have on my list). > It collects buddy icons. Due to past (and possibly present, not sure) bugs in Gaim, buddy icons were sometimes leaked. Also if two people use the same buddy icon, you get the file twice. If you've ever logged into Trepia on Gaim, you'll have gotten a lot of them from there too. I'd like to see this cache recoded, and so would shx. Something where each file is stored only once by using hashes, and where a database is kept and old unreferenced files are garbage collected. And also where unreferenced files can get re-referenced. Also, this database will probably get used for custom smileys. And I think someone is working on those. --Tim |
From: Felipe C. <fel...@gm...> - 2004-12-16 03:26:06
|
On Wed, 15 Dec 2004 17:57:26 -0600, Tim Ringenbach <om...@ho...> wrote: > Evan Schoenberg wrote: > > > What exactly does the cache in ~/.gaim/icons do? I currently have > > 56.6 MB of files in there (8,435 files, significantly more buddies > > than I have on my list). > > > > It collects buddy icons. Due to past (and possibly present, not sure) > bugs in Gaim, buddy icons were sometimes leaked. Also if two people use > the same buddy icon, you get the file twice. > > If you've ever logged into Trepia on Gaim, you'll have gotten a lot of > them from there too. > > I'd like to see this cache recoded, and so would shx. Something where > each file is stored only once by using hashes, and where a database is > kept and old unreferenced files are garbage collected. And also where > unreferenced files can get re-referenced. > > Also, this database will probably get used for custom smileys. And I > think someone is working on those. 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 don't know how does each prpl does buddy icons, but I think each one of them uses some kind of hash, at least if it does some kind of caching. 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. -- Felipe Contreras |