Menu
▾
▴
fofredux-devel
|
From: Andrew T. (nilspace) <nil...@us...> - 2005-12-10 19:55:45
|
Hey everyone - please hold off on commits to CVS for a day or two. I didn't realize which versions were which. Unless I hear otherwise, I'm calling the *current* CVSHEAD, Release Candidate v0.2 (perhaps 0.2.2 :) Anyways, in order to prevent confusion, don't check anything in until I let you know that I've tagged the repos. Thanks, Andy -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Kevin <ke...@dr...> - 2005-12-10 20:23:51
|
Andrew Turner (nilspace) wrote: >Hey everyone - please hold off on commits to CVS for a day or two. I >didn't realize which versions were which. > >Unless I hear otherwise, I'm calling the *current* CVSHEAD, Release >Candidate v0.2 (perhaps 0.2.2 :) Anyways, in order to prevent >confusion, don't check anything in until I let you know that I've >tagged the repos. > > > Problem: The feed image handling needs work. It doesn't work for me and the way it's implemented just has a bad smell. I'm of the opinion we should back that out until after the release. |
|
From: Katie B. <ka...@ho...> - 2005-12-11 09:02:29
|
On Sat, Dec 10, 2005 at 01:20:42PM -0700, Kevin wrote: > Problem: The feed image handling needs work. It doesn't work for me > and the way it's implemented just has a bad smell. I'm of the opinion > we should back that out until after the release. When you say the image handling doesn't work for you, is it not displying images for feeds that you know have them? Or are you getting some error? Could you share what you don't like about how it's implemented? -- Katie Bechtold http://hoteldetective.org/ |
|
From: Kevin <ke...@dr...> - 2005-12-11 23:19:05
|
Katie Bechtold wrote: >On Sat, Dec 10, 2005 at 01:20:42PM -0700, Kevin wrote: > > >>Problem: The feed image handling needs work. It doesn't work for me >>and the way it's implemented just has a bad smell. I'm of the opinion >>we should back that out until after the release. >> >> > >When you say the image handling doesn't work for you, is it not >displying images for feeds that you know have them? Or are you >getting some error? > >Could you share what you don't like about how it's implemented? > > > 1) My beef with the way it is implemented basically boils down to this: The way the image url is stored in the DB goes against standard normalization practices. The feed image URL is stored as a column in the items table. If the feed has 1000 items, the identical image URL is stored 1000 times in the db, when it really should only be stored once. (in the feed table, not the items table) I think this change should be made before release. It will be alot harder to do afterwards. 2) I have one feed where it shows the broken image icon, when the url is correct. What's strange is, this is the only feed out of 15 which have images that I know of.. I don't get what's different with this one feed. I've tried Firefox 1.5, Opera 8, and IE6. All do the same thing: When I view the feed items, it either shows a broken image icon, or nothing at all. Here's the rss url that is the problem: http://www.fark.com/fark.rss |
|
From: Katie B. <ka...@ho...> - 2005-12-12 15:02:07
|
On Sun, Dec 11, 2005 at 04:15:55PM -0700, Kevin wrote: > The way the image url is stored in the DB goes against standard > normalization practices. The feed image URL is stored as a column in > the items table. If the feed has 1000 items, the identical image URL > is stored 1000 times in the db, when it really should only be stored > once. (in the feed table, not the items table) I wrote to the original patch author asking why he implemented it that way -- it seems wrong to me, too -- and I got no response. So I plan to change it so the image URL is stored as a column in the feeds table instead ASAP. > I think this change should be made before release. It will be alot > harder to do afterwards. I agree; it will be a mess if we change it on users post-release. > 2) I have one feed where it shows the broken image icon, when the url is > correct. ... > Here's the rss url that is the problem: http://www.fark.com/fark.rss I'm seeing the same problem with that feed image, but I don't yet know how to explain it. -- Katie Bechtold http://hoteldetective.org/ |
|
From: Andrew T. (nilspace) <nil...@us...> - 2005-12-12 15:20:30
|
Ok - so we have a plan for resolving the RSS image storage? You can make use of the cache directory if that may help too (and check for updates on feed update? - at some point we probably want to add an "update feed settings" that will go through and attempt to rediscover lost feeds, grab any new metadata (name change, location change), and the favicon) Unfortunately, I think changes happened before and after this icon change. What do you all think about having Katie get these changes into 0.2. The alternative is rolling back around the RSS image changes. Thanks, Andy On 12/12/05, Katie Bechtold <ka...@ho...> wrote: > On Sun, Dec 11, 2005 at 04:15:55PM -0700, Kevin wrote: > > The way the image url is stored in the DB goes against standard > > normalization practices. The feed image URL is stored as a column in > > the items table. If the feed has 1000 items, the identical image URL > > is stored 1000 times in the db, when it really should only be stored > > once. (in the feed table, not the items table) > > I wrote to the original patch author asking why he implemented it > that way -- it seems wrong to me, too -- and I got no response. So > I plan to change it so the image URL is stored as a column in the > feeds table instead ASAP. > > > I think this change should be made before release. It will be alot > > harder to do afterwards. > > I agree; it will be a mess if we change it on users post-release. > > > 2) I have one feed where it shows the broken image icon, when the url i= s > > correct. ... > > Here's the rss url that is the problem: http://www.fark.com/fark.rss > > I'm seeing the same problem with that feed image, but I don't yet > know how to explain it. > > -- > Katie Bechtold http://hoteldetective.org/ > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Katie B. <ka...@ho...> - 2005-12-12 18:36:23
|
On Sun, Dec 11, 2005 at 04:15:55PM -0700, Kevin wrote: > 1) My beef with the way it is implemented basically boils down to this: > The way the image url is stored in the DB goes against standard > normalization practices. I've commited the change to the repository; the image URL is now stored in the feeds table rather than in the items table. > Here's the rss url that is the problem: http://www.fark.com/fark.rss What's happening there is fark's server checking the referrer field: $ wget http://img.fark.com/images/2002/links/fark.gif --13:30:51-- http://img.fark.com/images/2002/links/fark.gif => `fark.gif' Resolving img.fark.com... 207.58.150.106 Connecting to img.fark.com|207.58.150.106|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 788 [image/gif] 100%[====================================================================>] 788 --.--K/s 13:30:51 (39.55 MB/s) - `fark.gif' saved [788/788] $ wget --referer='http://somewhere.else.com/' http://img.fark.com/images/2002/links/fark.gif --13:27:37-- http://img.fark.com/images/2002/links/fark.gif => `fark.gif.1' Resolving img.fark.com... 207.58.150.106 Connecting to img.fark.com|207.58.150.106|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 13:27:37 ERROR 403: Forbidden. -- Katie Bechtold http://hoteldetective.org/ |
|
From: Kevin <ke...@dr...> - 2005-12-12 18:45:02
|
> On Sun, Dec 11, 2005 at 04:15:55PM -0700, Kevin wrote: >> 1) My beef with the way it is implemented basically boils down to this= : >> The way the image url is stored in the DB goes against standard >> normalization practices. > > I've commited the change to the repository; the image URL is now > stored in the feeds table rather than in the items table. > > >> Here's the rss url that is the problem: http://www.fark.com/fark.rss > > What's happening there is fark's server checking the referrer field: Good catch. What are the possible workarounds? One way I can think of is to cache th= e image file locally, either on the filesystem or in the DB. --=20 Kevin |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X