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

Re: [rest-discuss] Atom and prev links

Expand Messages
  • Ben Niven-Jenkins
    ... Why not use feed paging and use prev-archive to indicate the previous page and keep your main feed as the current page. Client just polls the current
    Message 1 of 23 , Jun 28, 2013
    • 0 Attachment
      On 28 Jun 2013, at 11:16, Greg Young <gregoryyoung1@...> wrote:

      > We have a mature atom implementation for distribution of event streams
      > and as always the devil is in the details...
      >
      > The issue revolves around prev links. At some point on an atom feed
      > you will hit the current item, prev will point to the next item that
      > does not yet exist.

      Why not use feed paging and use prev-archive to indicate the previous page and keep your "main" feed as the current page.

      Client just polls the current page and if it needs to go further back in time it follows prev-archive links until it finds what it wants.

      You then avoid the problem of links to things that don't exist or updating already archived pages.

      Ben
    • Greg Young
      Our whole feed is nonlossy and immutable. ... -- Le doute n est pas une condition agréable, mais la certitude est absurde. Our whole feed is nonlossy and
      Message 2 of 23 , Jun 28, 2013
      • 0 Attachment
        Our whole feed is nonlossy and immutable.

        On Friday, June 28, 2013, Ben Niven-Jenkins wrote:


        On 28 Jun 2013, at 11:16, Greg Young <gregoryyoung1@...> wrote:

        > We have a mature atom implementation for distribution of event streams
        > and as always the devil is in the details...
        >
        > The issue revolves around prev links. At some point on an atom feed
        > you will hit the current item, prev will point to the next item that
        > does not yet exist.

        Why not use feed paging and use prev-archive to indicate the previous page and keep your "main" feed as the current page.

        Client just polls the current page and if it needs to go further back in time it follows prev-archive links until it finds what it wants.

        You then avoid the problem of links to things that don't exist or updating already archived pages.

        Ben


        --
        Le doute n'est pas une condition agréable, mais la certitude est absurde.
      • Ben Niven-Jenkins
        ... Can you expand on what you mean by this. Feed archiving doesn t lose information and doesn t require changes to a page once it is first generated. Or do
        Message 3 of 23 , Jun 28, 2013
        • 0 Attachment


          On 28 Jun 2013, at 18:32, Greg Young <gregoryyoung1@...> wrote:

          Our whole feed is nonlossy and immutable.

          Can you expand on what you mean by this. Feed archiving doesn't lose information and doesn't require changes to a page once it is first generated. 

          Or do you mean the client cannot handle the content of the URI that represents the entry point into the feed changing and expects the content of that URI to stay always constant so the clients needs to page "forward in time" to find the latest entries?

          Ben

          On Friday, June 28, 2013, Ben Niven-Jenkins wrote:


          On 28 Jun 2013, at 11:16, Greg Young <gregoryyoung1@...> wrote:

          > We have a mature atom implementation for distribution of event streams
          > and as always the devil is in the details...
          >
          > The issue revolves around prev links. At some point on an atom feed
          > you will hit the current item, prev will point to the next item that
          > does not yet exist.

          Why not use feed paging and use prev-archive to indicate the previous page and keep your "main" feed as the current page.

          Client just polls the current page and if it needs to go further back in time it follows prev-archive links until it finds what it wants.

          You then avoid the problem of links to things that don't exist or updating already archived pages.

          Ben


          --
          Le doute n'est pas une condition agréable, mais la certitude est absurde.
        • Greg Young
          We could do all over prev next even with no archiving. Every uri we create is immutable. Spec defines additional logic needed for prev/next which is unneeded
          Message 4 of 23 , Jun 28, 2013
          • 0 Attachment
            We could do all over prev next even with no archiving. Every uri we create is immutable. Spec defines additional logic needed for prev/next which is unneeded for us so archive gives us a simpler client API (also explicit that we are non lossy)

            On Friday, June 28, 2013, Ben Niven-Jenkins wrote:


            On 28 Jun 2013, at 18:32, Greg Young <gregoryyoung1@...> wrote:

            Our whole feed is nonlossy and immutable.

            Can you expand on what you mean by this. Feed archiving doesn't lose information and doesn't require changes to a page once it is first generated. 

            Or do you mean the client cannot handle the content of the URI that represents the entry point into the feed changing and expects the content of that URI to stay always constant so the clients needs to page "forward in time" to find the latest entries?

            Ben

            On Friday, June 28, 2013, Ben Niven-Jenkins wrote:


            On 28 Jun 2013, at 11:16, Greg Young <gregoryyoung1@...> wrote:

            > We have a mature atom implementation for distribution of event streams
            > and as always the devil is in the details...
            >
            > The issue revolves around prev links. At some point on an atom feed
            > you will hit the current item, prev will point to the next item that
            > does not yet exist.

            Why not use feed paging and use prev-archive to indicate the previous page and keep your "main" feed as the current page.

            Client just polls the current page and if it needs to go further back in time it follows prev-archive links until it finds what it wants.

            You then avoid the problem of links to things that don't exist or updating already archived pages.

            Ben


            --
            Le doute n'est pas une condition agréable, mais la certitude est absurde.


            --
            Le doute n'est pas une condition agréable, mais la certitude est absurde.
          • Greg Young
            To be clear we want a cross of prev and archive prev as they were obviously designed for mutable feeds. ... -- Le doute n est pas une condition agréable, mais
            Message 5 of 23 , Jun 28, 2013
            • 0 Attachment
              To be clear we want a cross of prev and archive prev as they were obviously designed for mutable feeds.

              On Friday, June 28, 2013, Greg Young wrote:
              We could do all over prev next even with no archiving. Every uri we create is immutable. Spec defines additional logic needed for prev/next which is unneeded for us so archive gives us a simpler client API (also explicit that we are non lossy)

              On Friday, June 28, 2013, Ben Niven-Jenkins wrote:


              On 28 Jun 2013, at 18:32, Greg Young <gregoryyoung1@...> wrote:

              Our whole feed is nonlossy and immutable.

              Can you expand on what you mean by this. Feed archiving doesn't lose information and doesn't require changes to a page once it is first generated. 

              Or do you mean the client cannot handle the content of the URI that represents the entry point into the feed changing and expects the content of that URI to stay always constant so the clients needs to page "forward in time" to find the latest entries?

              Ben

              On Friday, June 28, 2013, Ben Niven-Jenkins wrote:


              On 28 Jun 2013, at 11:16, Greg Young <gregoryyoung1@...> wrote:

              > We have a mature atom implementation for distribution of event streams
              > and as always the devil is in the details...
              >
              > The issue revolves around prev links. At some point on an atom feed
              > you will hit the current item, prev will point to the next item that
              > does not yet exist.

              Why not use feed paging and use prev-archive to indicate the previous page and keep your "main" feed as the current page.

              Client just polls the current page and if it needs to go further back in time it follows prev-archive links until it finds what it wants.

              You then avoid the problem of links to things that don't exist or updating already archived pages.

              Ben


              --
              Le doute n'est pas une condition agréable, mais la certitude est absurde.


              --
              Le doute n'est pas une condition agréable, mais la certitude est absurde.


              --
              Le doute n'est pas une condition agréable, mais la certitude est absurde.
            Your message has been successfully submitted and would be delivered to recipients shortly.