[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RSS2-Support] Re: RSS 2.0 amendments process?



> > You could always consider using .cab or .zip archive type files.
> > 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? ;)

Well, using e-mail programs as an example of the value behind attachments isn't
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.

"ed2k://|file|index.rdf|12290|b3bab55a59d062133a6d48d87b5a8b0e|"

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
with it.

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.

-Bill Kearney