Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Bill Kearney
    ... 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
    Message 1 of 36 , Oct 2, 2003
      > > 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.


      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
    • petite_lapin_blue
      Dear Mr him , ... You are presuming a very narrow usage pattern. And what s wrong with http encoding? ... Adverse is to the point. If you use any type of
      Message 36 of 36 , Oct 4, 2003
        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
        to disagree.

        > 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
        to me.

        (3) I create one RSS item with multiple enclosures. End of the story. Unity of action.
        No ambiguity.




        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.
      Your message has been successfully submitted and would be delivered to recipients shortly.