Re: [RSS2-Support] Re: RSS 2.0 amendments process?
> > You could always consider using .cab or .zip archive type files.Well, using e-mail programs as an example of the value behind attachments isn't
> > Windows 2000
> > and XP directly support using them from the filesystem as transparent
> > folders
> > (up to a point). They are an extra processing step but consider that
> > they also
> > offer the ability to pass along filesystem hierarchy information.
> To much of a "workaround". Transparency is important. I just need
> multiple attachments like any self respecting email can handle for the
> last decade. Is that too much to ask? ;)
exactly a ringing endorsement. Look at all the insanity attachments have
caused! Viruses, malicious executables and the like. Ugh, that's quite a mess.
Given how neatly .zip archive handling is integrated these days there's really
not much excuse for not using them. Of course they will require the reader
program take additional steps but so would mutliple enclosure elements. I'm not
saying multiple enclosures is a bad idea. I'm suggesting that using archives
might help avoid a whole range of /other/ problems at the same time.
It would be greatly helpful to have a table of 'valid' MIME types that are
supported by enclosures. Best to act proactively to help reader programs
understand how to properly go about dealing with things like executables,
archives and other types.
Granted, this raises the hassle of how to deal with a zip file that contains a
media file or multiple media files.
The original intent of enclosures was to push big Quicktime movies out to
desktops. The idea was that the desktop running Radio Userland would be left on
overnight (ignoring the waste of electricity /this/ causes) and would then go
get the data without bogging down the users actual live use of their network
connection. It's a good idea, perhaps a little poorly thought out though. But
it worked at the time and made for a cool demo hack.
It may well be time to look into larger delivery issues instead of trying to
force this upon the enclosure element.
Stuff like using ed2k:// urls is one example.
That'll get you a copy of my RSS feed via eDonkey. If you fire up eDonkey and
give it that URL you should be able to have it (eventually) download you a copy
of my feed.
Other p2p systems could be employed as well. Using them, however, raises a
number of issues that would probably need to be discussed. Stuff like
determining current and/or latest version, authentication, naming conventions,
etc. But it can be done. All it takes is for a reader program to make use of
it's host operating system's ability to transport the data. If the app is
hard-coded to do only http transfers then you're screwed. It's a whole lot
better to use the OS transports as you get all their development goodness along
This really isn't an RSS2 issue, perhaps it should be discussed in another group
like the syndication list? No need to yank the RSS2 focus off into this area if
other lists are better suited.
- Dear Mr "him",
On Friday, Oct 3, 2003, at 20:38 Europe/Amsterdam, houghtoa wrote:
> You missed the point, but worst, are reckless about bandwidth issues.
You are presuming a very narrow usage pattern. And what's wrong with http
> "Adverse" is rather strong.
"Adverse" is to the point. If you use any type of aggregate format you will need a two
steps process: get a "bill of materials". Then get the content. It would be very
unfortunate if to get the BOM you need to get the entire content.
> Surely this was sarcasm. How can you comment that it's just like mail attachments.
Surely it was. I happen to have some exposure to the inner working of email:
This doesn't make me an authority on the matter though.
> You missed the point again.
Nope. I got your point. But perhaps you didn't get mine. Which is ok. We could agree
> As someone else pointed out, if you don't want to use an archiving mechanism
> then use multiple items, yet another solution for working *within*
> the current specification.
Ok. Let me illustrate my "circumstances" more concretely. This will most likely require
a great leap of faith on your side, but I'm sure you can manage.
Lets assume that I want to publish a RSS item regarding a forthcoming meeting. The
meeting is about some random corporate activities. I also spent some time preparing
supporting materials for this forthcoming event: a document describing the agenda, a
spreadsheet with some nice pie charts and a presentation outline. Those materials are
related to this event. They are not random artifacts. Now, if I want to attach this
material with my RSS item, what do I do?
(1) I use one enclosure and package all the materials in some sort of archive.
Workable for sure. But cumbersome. And I'm loosing the information about what's in
the archive. Instead of a Word document, an Excel spreadsheet and a PowerPoint
presentation, I now have an amorphous blob. Sure, I could dig into this archive to
retrieve its content. But then I will need to make the assumption that this archive is
just a wrapper for its content. And not the content itself. How do I distinguish
between an enclosure which points to an archive and an enclosure which point to a
wrapper? This introduce ambiguity of intend.
(2) I create multiple RSS item for this event: perhaps one for the event itself. And one
for each document. Something like: here is the event. And here is a document. And
here is a spreadsheet. And here is a presentation. Workable for sure. But I lose the
"unity of action". Instead of having one RSS item with some attached materials, I now
have four different items with nothing to link them together. Sounds like a dead end
(3) I create one RSS item with multiple enclosures. End of the story. Unity of action.
Why don't you also apply your phenomenal analytical power to the other three topics
at hand? Would love to hear your personal take on them.