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

FriendFeed's Simple Update Protocol

Expand Messages
  • rcade
    FriendFeed is working on Simple Update Protocol (SUP), a means of discovering when feeds on a particular service have been updated without polling the
    Message 1 of 11 , Dec 6, 2008
    View Source
    • 0 Attachment
      FriendFeed is working on Simple Update Protocol (SUP), a means of
      discovering when feeds on a particular service have been updated
      without polling the individual feeds:

      http://code.google.com/p/simpleupdateprotocol/

      Feeds indicate their updates can be tracked with SUP by using a new
      channel-link tag, as in this example from an Atom feed:

      <link rel="http://api.friendfeed.com/2008/03#sup"
      href="http://friendfeed.com/api/sup.json#53924729"
      type="application/json" />

      The rel attribute identifies an ID for the feed, called its SUP-ID.
      The href attribute contains a URL that uses JSON data to identify
      updated feeds by their SUP-IDs.

      My first take on the protocol is that defining a relationship with a
      URI is too different than standard link relationships in HTML:

      http://www.w3.org/TR/REC-html40/types.html#type-links

      Also, neither RSS 1.0 nor RSS 2.0 allows multiple channel-link tags,
      so this would only be valid in an Atom feed.

      Both of these concerns could be addressed by identifying the SUP
      provider with a new namespace like this:

      <rss xmlns:sup="http://friendfeed.com/api/sup/">
      <channel>
      <sup:provider href="http://friendfeed.com/api/sup.json#53924729"
      type="application/json" />
      ...

      If the definition of the channel-cloud element wasn't tied so closely
      to remote procedure calls, it could have been used to identify a sup
      provider.
    • rcade
      After posting I found an alternative idea employed by Six Apart -- an update stream in Atom format with updates from any TypePad or Vox blog:
      Message 2 of 11 , Dec 6, 2008
      View Source
      • 0 Attachment
        After posting I found an alternative idea employed by Six Apart -- an
        update stream in Atom format with updates from any TypePad or Vox blog:

        http://updates.sixapart.com/

        There's also something Radio UserLand does -- a channel-category tag:

        <category
        domain="http://rpc.weblogs.com/shortChanges.xml">rssUpdates>/category>

        The domain is a changes.xml file on a Weblogs.Com-style ping server.
      • rcade
        I added an issue to SUP s home page on Code.Google.Com about the use of invalid RSS: http://code.google.com/p/simpleupdateprotocol/issues/detail?id=3 That page
        Message 3 of 11 , Dec 6, 2008
        View Source
        • 0 Attachment
          I added an issue to SUP's home page on Code.Google.Com about the use
          of invalid RSS:

          http://code.google.com/p/simpleupdateprotocol/issues/detail?id=3

          That page permits comments, so it's a way to reach the SUP creators
          with feedback on this issue and others.
        • Charles Iliya Krempeaux
          Hello, ... AFAIK, Atom requires you to use URLs for non-standard rel attribute values. So what SUP is doing for the rel attribute is correct. ... You
          Message 4 of 11 , Dec 6, 2008
          View Source
          • 0 Attachment
            Hello,

            On Sat, Dec 6, 2008 at 7:48 AM, rcade <cadenhead@...> wrote:
            > FriendFeed is working on Simple Update Protocol (SUP), a means of
            > discovering when feeds on a particular service have been updated
            > without polling the individual feeds:
            >
            > http://code.google.com/p/simpleupdateprotocol/
            >
            > Feeds indicate their updates can be tracked with SUP by using a new
            > channel-link tag, as in this example from an Atom feed:
            >
            > <link rel="http://api.friendfeed.com/2008/03#sup"
            > href="http://friendfeed.com/api/sup.json#53924729"
            > type="application/json" />
            >
            > The rel attribute identifies an ID for the feed, called its SUP-ID.
            > The href attribute contains a URL that uses JSON data to identify
            > updated feeds by their SUP-IDs.
            >
            > My first take on the protocol is that defining a relationship with a
            > URI is too different than standard link relationships in HTML:
            >
            > http://www.w3.org/TR/REC-html40/types.html#type-links

            AFAIK, Atom requires you to use URLs for non-standard "rel" attribute
            values. So what SUP is doing for the "rel" attribute is correct.

            > Also, neither RSS 1.0 nor RSS 2.0 allows multiple channel-link tags,
            > so this would only be valid in an Atom feed.
            >
            > Both of these concerns could be addressed by identifying the SUP
            > provider with a new namespace like this:
            >
            > <rss xmlns:sup="http://friendfeed.com/api/sup/">
            > <channel>
            > <sup:provider href="http://friendfeed.com/api/sup.json#53924729"
            > type="application/json" />
            > ...

            You could also just use Atomic RSS...

            http://www.tbray.org/ongoing/When/200x/2005/07/27/Atomic-RSS

            ... and get...

            <rss xmlns:atom="http://www.w3.org/2005/Atom">
            <channel>
            <atom:link rel="http://api.friendfeed.com/2008/03#sup"
            href="http://friendfeed.com/api/sup.json#53924729"
            type="application/json" />
            ...

            That way SUP looks basically the same in Atom and RSS.

            --
            Charles Iliya Krempeaux, B.Sc.
            http://changelog.ca/
          • rcade
            ... Interesting -- I wasn t aware of that. I tried to check it in the Atom format spec, but I don t understand this sentence: The value of rel MUST be a
            Message 5 of 11 , Dec 6, 2008
            View Source
            • 0 Attachment
              --- In rss-public@yahoogroups.com, "Charles Iliya Krempeaux"
              <supercanadian@...> wrote:
              > AFAIK, Atom requires you to use URLs for non-standard "rel" attribute
              > values. So what SUP is doing for the "rel" attribute is correct.

              Interesting -- I wasn't aware of that. I tried to check it in the Atom
              format spec, but I don't understand this sentence:

              "The value of "rel" MUST be a string that is non-empty and matches
              either the "isegment-nz-nc" or the "IRI" production in [RFC3987]."

              http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.link

              Which part of that means it's OK to define new relationships as IRIs
              instead of getting IANA approval for your new rel value?

              > <atom:link rel="http://api.friendfeed.com/2008/03#sup"
              > href="http://friendfeed.com/api/sup.json#53924729"
              > type="application/json" />
              > ...

              Are you aware of any IRI-based relationships that are currently in use
              employing atom:link in feeds?
            • Aristotle Pagaltzis
              ... The sentence directly following that one. If a name is given, implementations MUST consider the link relation type equivalent to the same name registered
              Message 6 of 11 , Dec 7, 2008
              View Source
              • 0 Attachment
                * rcade <cadenhead@...> [2008-12-07 02:15]:
                > I tried to check it in the Atom format spec, but I don't
                > understand this sentence:
                >
                > "The value of "rel" MUST be a string that is non-empty and
                > matches either the "isegment-nz-nc" or the "IRI" production in
                > [RFC3987]."
                >
                > http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.link
                >
                > Which part of that means it's OK to define new relationships as
                > IRIs instead of getting IANA approval for your new rel value?

                The sentence directly following that one.

                If a name is given, implementations MUST consider the link
                relation type equivalent to the same name registered within
                the IANA Registry of Link Relations (Section 7), and thus to
                the IRI that would be obtained by appending the value of the
                rel attribute to the string
                "http://www.iana.org/assignments/relation/".

                IANA is the authority for iana.org URIs, but you are free to use
                your own.

                Regards,
                --
                Aristotle Pagaltzis // <http://plasmasturm.org/>
              • Charles Iliya Krempeaux
                Hello, ... [...] ... Well, obviously anyone can create an Atom URL/URI/IRI/whatever-you-want-to-call-them rel extension... and I ve even done it for in
                Message 7 of 11 , Dec 7, 2008
                View Source
                • 0 Attachment
                  Hello,

                  On Sat, Dec 6, 2008 at 5:13 PM, rcade <cadenhead@...> wrote:
                  > --- In rss-public@yahoogroups.com, "Charles Iliya Krempeaux"
                  >
                  > <supercanadian@...> wrote:

                  [...]

                  > Are you aware of any IRI-based relationships that are currently in use
                  > employing atom:link in feeds?

                  Well, obviously anyone can create an Atom
                  URL/URI/IRI/whatever-you-want-to-call-them "rel" extension... and I've
                  even done it for "in house" software. But I'm guessing you mean ones
                  in the wild. Well there's SUP. Atom threading was initially
                  done/proposed that way too I think. (See:
                  http://www.ibm.com/developerworks/xml/library/x-atom10.html for
                  example.) But I don't really know of any others.

                  --
                  Charles Iliya Krempeaux, B.Sc.
                  http://changelog.ca/
                • Sam Ruby
                  ... Neither place any limits on the number of atom:link elements in such contexts. Atom links with a rel= self are already commonplace in RSS 2.0 feeds. -
                  Message 8 of 11 , Dec 7, 2008
                  View Source
                  • 0 Attachment
                    rcade wrote:
                    >
                    > Also, neither RSS 1.0 nor RSS 2.0 allows multiple channel-link tags,
                    > so this would only be valid in an Atom feed.

                    Neither place any limits on the number of atom:link elements in such
                    contexts. Atom links with a rel="self" are already commonplace in RSS
                    2.0 feeds.

                    - Sam Ruby
                  • rcade
                    ... True. But the documentation for SUP doesn t say that RSS publishers should use atom:link in their feeds to define a provider. The docs just say to add a
                    Message 9 of 11 , Dec 7, 2008
                    View Source
                    • 0 Attachment
                      --- In rss-public@yahoogroups.com, Sam Ruby <rubys@...> wrote:
                      > Neither place any limits on the number of atom:link elements in such
                      > contexts. Atom links with a rel="self" are already commonplace in
                      > RSS 2.0 feeds.

                      True. But the documentation for SUP doesn't say that RSS publishers
                      should use atom:link in their feeds to define a provider. The docs
                      just say to add a link tag.
                    • Charles Iliya Krempeaux
                      Hello ... Seems like quite the hack. -- Charles Iliya Krempeaux, B.Sc. http://changelog.ca/
                      Message 10 of 11 , Dec 7, 2008
                      View Source
                      • 0 Attachment
                        Hello


                        On Sat, Dec 6, 2008 at 8:45 AM, rcade <cadenhead@...> wrote:
                        > After posting I found an alternative idea employed by Six Apart -- an
                        > update stream in Atom format with updates from any TypePad or Vox blog:
                        >
                        > http://updates.sixapart.com/
                        >
                        > There's also something Radio UserLand does -- a channel-category tag:
                        >
                        > <category
                        > domain="http://rpc.weblogs.com/shortChanges.xml">rssUpdates>/category>
                        >
                        > The domain is a changes.xml file on a Weblogs.Com-style ping server.

                        Seems like quite the hack.

                        --
                        Charles Iliya Krempeaux, B.Sc.
                        http://changelog.ca/
                      • James Holderness
                        ... I know Google uses IRI-based relationships in number of their feeds. Have a look on Google calendar and Picasa for some examples. Not that I d necessarily
                        Message 11 of 11 , Dec 7, 2008
                        View Source
                        • 0 Attachment
                          rcade wrote:
                          > Are you aware of any IRI-based relationships that are currently in use
                          > employing atom:link in feeds?

                          I know Google uses IRI-based relationships in number of their feeds. Have a
                          look on Google calendar and Picasa for some examples.

                          Not that I'd necessarily recommend anything that Google is doing, but if
                          you're just looking for examples...

                          Regards
                          James
                        Your message has been successfully submitted and would be delivered to recipients shortly.