Re: PHP wonks? Wordpress enclosure hack needed
- --- In firstname.lastname@example.org, "Andreas Haugstrup"
> What happens the day you put up an audio file? Does the MP3 filego in the
> Quicktime feed or the WMV feed? Which feed does the Ogg Vorbisfile go
> into? What happens when you put up a PDF and a Word version of thesame
> document? What goes where?Well, I understand this argument - and it's the fundamental argument
for mRSS. I just think it puts a lot of burden on the aggregator to
impose selection and logic to the process. Let's say someone uses
mRSS to post coverage of a speech. They post the audio as WAV, MP3,
WMV and FLAC. They post the video as MOV, WMV, MP4, and say AVI.
It's all the same "item." (this is a stretch I know, but entirely
within spec as I understand it).
Now my aggregator needs to decide what to grab. Both audio and
video? Preference rules? Now which format: do I impose a cascade on
it? What if the contents in 3 different resolutions, and WMV is the
highest, but I prefer MOV most of the time?
It can get ugly fast, and forcing the user to choose for each item
is a terrible solution, as it defeats all of the advantages of
caching. Downloading everything is obviously a hugely innefficient
So the response is likely "well its up to the content owner to be
really logical about how they package their stuff"
Which leads us back to 'why not just use one format per feed.'
Life would be so much easier if someone (deus ex machina) picked a
format for us, but then, that would be cowtowing to someone like
- On Wed, 01 Jun 2005 16:17:45 +0200, dnadig <dnadig@...> wrote:
> Well, I understand this argument - and it's the fundamental argumentIt puts the burden on the aggregator and the reader. Who else should the
> for mRSS. I just think it puts a lot of burden on the aggregator to
> impose selection and logic to the process.
burden be on? The alternative is to not mix and match media in blogs, and
that would be very sad.
> It can get ugly fast, and forcing the user to choose for each itemYou say 'ugly' I say 'beautiful'. :o)
> is a terrible solution, as it defeats all of the advantages of
> caching. Downloading everything is obviously a hugely innefficient
> answer too.
The idea of pre-fetching the content (overnight or whatever) is not
something I'm a fan of to begin with. For the very reason you outline: My
computer *can't* always guess what I want. It can do it some of the time.
The pre-fetching started with podcasting, and their
I'll-just-send-you-this-1-hour-audio-file-radio-show-deal. For blogging
it's just not necessary. I don't pre-fetch Eric Rice's audio blog posts,
there's just no need. I don't pre-fetch videoblog, there's no need. I
click play, wait a second, and the video begins playing while it downloads.
Pre-fetching would be a bigger waste of bandwidth, since I'd be
downloading a lot of video I'd never see.
Anyway, I say beautiful because I imagine a more clever aggregator that
would serve me my options for reading/viewing/listening with each blog
post. A little sidebar with links to the mp3, wav, mov and wmv files. One
day I'll want to watch on my computer and I'll grab the mov from the
aggregator, the next day I'm going biking so I'll load the mp3 to my iPod.
> So the response is likely "well its up to the content owner to beCan't do that. I don't even know what I'm having for dinner tomorrow,
> really logical about how they package their stuff"
there's no way I can tell you what kinds of files I'll be posting to my
blog next month. I've sent weird stuff like Photoshop files and even an
RSS file as enclosures in the past. Who knows what tomorrow brings?
Commentary on media, communication, culture and technology.