Hello, Jay! On Wed, 2007-10-31 at 15:03 +0000, Jay Bradley wrote: > I can see why you chose hashes and can also see I'm a bit naive. > Things always look simple until you have to do them yourself. From > your description I can see that gpodder needs guaranteed unique > directory and file names. I presume (but correct me if I'm wrong) that > cases when the title is missing, contains characters unsuitable for > file or directory names, is longer than a desired maximum length or is > a duplicate are outlying cases.
These are the exact cases when using the title is not possible, although they _do_ happen with certain feeds. People will complain about a feed not working if one of these cases happens and is not handled correctly. > That is, the title is only unsuitable quite rarely. If this is the > case then I would advocate using hashes as a fallback system. So if > it's possible to use the title according to some set rules then the > title is used and if not then use a hash. That would be an option, although it makes the code more complex and therefore error-prone. If we change the algorithm used to determine the file names (a better algorithm comes up, bugs are fixed, ...), it could be possible that episodes downloaded now will not be accessible and reachable by newer gPodder versions. Another problem I see with your approach is how to handle duplicates (we have to save the files with unique filenames, but then also get the right unique filename from a title). This has to be handled with another file that has to save the generated name (so we have a URL->unique name mapping). In my opinion, it's just too much housekeeping and invites a bunch of problems. As I mentioned in my earlier mail, if RSS feeds would be "sane", and we could trust their content, it would be much easier indeed (just look at the feed loading code in libpodcasts.py). > If the set rules are always used then the program can always tell if > it should use the title or a hash. Yes, but it also makes it difficult for other programs to determine the filename of a feed or episode given the URL. Other programs that want to operate on gPodder's download folder then have to know (and import or implement) the exact algorithm used in gPodder, and you can imagine what happens when this algorithm changes and other programs are not updated with the new algorithm. The title/hash method is theoretically very nice, but makes maintaining all those bits and pieces cumbersome. What I'd rather implement is a way of doing a "mirror" with hard links to files on your local hard drive. Unfortunately, hard links are not supported by the FAT filesystem, and I have heard some users have their gPodder download directory set to a FAT drive/usb stick. Hard links are necessary to not duplicate disk space requirements (like a soft link, but it appears as regular file). Thomas _______________________________________________ gpodder-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/gpodder-devel
