Knowing when you've reached the last entry

[Eric Silva (Nokia)]

Hi All,

We're using Activity Streams for a project here at Nokia.

When using Activity Streams, how does the consumer of the feed
typically know when to stop asking for more entries? I.e., is there a
"has more" or "last" identifier on feed entries? I couldn't find
anything of the sort.

We're trying to figure out a way of knowing when to display a "more"
button, etc.

I searched this group, the wiki, etc. and I couldn't find an example
of this.

Any help would be appreciated.

Thanks,

Eric Silva
Nokia

[Martin Atkins]

On 02/04/2010 08:48 AM, Eric Silva (Nokia) wrote:
> Hi All,
>
> We're using Activity Streams for a project here at Nokia.
>
> When using Activity Streams, how does the consumer of the feed
> typically know when to stop asking for more entries? I.e., is there a
> "has more" or "last" identifier on feed entries? I couldn't find
> anything of the sort.
>
> We're trying to figure out a way of knowing when to display a "more"
> button, etc.
>
> I searched this group, the wiki, etc. and I couldn't find an example
> of this.
>

Activity Streams currently doesn't specify anything except how one or
more activities can be represented as an Atom entry. Most Atom feeds
don't support retrieving anything more than a predefined number of most
recent entries, so in that situation you cannot retrieve "more".

Some publishers may offer a mechanism to retrieve further entries, but
that will necessarily be proprietary to that publisher so you'd have to
consult their documentation.

RFC5005[1] does define a means of declaring in a feed how to retrieve
the next page, for two different definitions of "next page", but as far
as I'm aware it hasn't seen any real adoption so isn't really of
anything more than academic interest right now.

[1] http://www.ietf.org/rfc/rfc5005.txt - Feed Paging and Archiving

[Rob Dolin]

FWIW, my team is considering <link rel="next" .../> as in the spec Martin suggested:

http://www.ietf.org/rfc/rfc5005.txt

--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.

[Chris Messina]

One of the next steps is to create an API service for both retrieving
and creating activities. We can of course use AtomPub + PubSubHubBub
(PSHB) and an ActivityStream object, but it would also be good if we
could take the API model of Portable Contacts (PoCo) and apply it to
AS, so that we have a generic querystring-based mechanism for getting
at more specific chucks of data.

It'd be possible to approach this RESTfully as well, but I'm more
interested in walking down established paths than paving relatively
new ones just yet.

Chris

Sent from my iPhone 2G

> To post to this group, send email to activity-
> str...@googlegroups.com.

> To unsubscribe from this group, send email to activity-strea...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en
> .
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Activity Streams" group.

> To post to this group, send email to activity-
> str...@googlegroups.com.

[Bruno Pedro]

Hi,

My 2 cents: assuming that you own the producer of the feed you can
easily encapsulate OpenSearch meta-information into it, describing
exactly what you need. Example:

<opensearch:startIndex>1</opensearch:startIndex>
<opensearch:itemsPerPage>10</opensearch:itemsPerPage>
<opensearch:totalResults>1175</opensearch:totalResults>

Here's a link to the relevante part of the OpenSearch spec:
http://www.opensearch.org/Specifications/OpenSearch/1.1#Example_of_OpenSearch_response_elements_in_Atom_1.0

Hope it helps.

[Bill de hOra]

Hi Eric,

You can use rfc5005 pagination links in combination with caching the
id/updated values of the entry. It works like this for clients that are
polling

Initial Fetch:

- Fetch the activity stream feed

- Follow as many "next" links as you want

- cache the last id/updated pair you see, call this cache1.

Subsequent Fetch

- Fetch the activity stream feed

- cache the first entry's id/updated pair, call this cache2.

- step through the id/updated pairs in the feed, this might involve
following next links.

- When until you see the id/updated pair from cache1, you're done
updating.

- replace cache1 with cache2 to prepare for the next fetch cycle.

The assumption here is that the entries are ordered by their
atom:updated element. It might be worth saying something about that in
the spec.

For comet/longpoll or push the approach would be different.

Bill

[Bill de hOra]

rfc5005 is pretty well established, being an Internet standard ;)

It's a pity that PoCo is locked into XRDS (abandoned), OAuth1.0 (OAuth
under development in the IETF), and Basic Auth (without requiring TLS,
which is bad practice), xs:dateTime (subsets Atom date constructs).
Probably the spec should be revved and modularised to break out the
format, api model etc, so the overall dependencies are properly managed.

For example, updatedSince is worthy of its own module spec in AS, the
amount of data transfer it can reduce in simple poll scenarios is
immense if the server is willing to compute the difference for the client.

Bill

>> To post to this group, send email to activity...@googlegroups.com.

>> To unsubscribe from this group, send email to
>> activity-strea...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/activity-streams?hl=en.
>>
>>

>> --
>> You received this message because you are subscribed to the Google
>> Groups "Activity Streams" group.

>> To post to this group, send email to activity...@googlegroups.com.

[Chris Messina]

Would you be willing to take a crack at that, Bill?

Chris

Chris Messina
Open Web Advocate, Google

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

This email is:   [ ] shareable    [X] ask first   [ ] private

[John Panzer]

rel="next" (and rel="prev") is the standard way to do pagination in Atom feeds, with lots of prior art.

[Chris Messina]

But that doesn't necessarily tell you when you've hit the last of the feed content, right?

It just tells you to keep paging out?

Maybe Eric can be more specific about his use case?

Chris

[John Panzer]

We (well, jsmarr) should update PoCo to use XRD.  I'm pretty sure it requires Basic Auth-to-be-configurable but not mandated to offer in any particular situation.  Since auth is modular it's not a big deal to add additional auth in the future as needed.

On Sat, Feb 20, 2010 at 2:47 PM, Bill de hOra <bi...@dehora.net> wrote:

[John Panzer]

On Sat, Feb 20, 2010 at 2:51 PM, Chris Messina <chris....@gmail.com> wrote:

But that doesn't necessarily tell you when you've hit the last of the feed content, right?

Sure it does -- no link rel="next" means there is no next...

(This also lets feed providers stick continuation tokens of their own devising into the next-links which can be really helpful.)

[Chris Messina]

On Sat, Feb 20, 2010 at 2:53 PM, John Panzer <jpa...@google.com> wrote:

On Sat, Feb 20, 2010 at 2:51 PM, Chris Messina <chris....@gmail.com> wrote:

But that doesn't necessarily tell you when you've hit the last of the feed content, right?

Sure it does -- no link rel="next" means there is no next...

(This also lets feed providers stick continuation tokens of their own devising into the next-links which can be really helpful.)

Ah, I get it. Ok, that makes sense.

Not bad.