Feed organization and URIs

[dstillman]

Continuing from aurimasv@89af196#commitcomment-13328005

Well, I think we definitely want to sync feeds. At least the feed URLs for now. Ideally read/unread state as well. Then there's also the possibility that a user deletes an item from the feed and he/she would probably expect that to sync as well.

Feed subscriptions and read state, yes. I don't think we need/want to sync individual items, though — that's a significant additional syncing burden for something that each client (even the website) could easily fetch independently.

I also don't think we need feed item deletion, let alone syncing of it. Many feed readers just have read state, with an expiration setting for read items, and it's accepted that the feed view matches at least the items currently in the feed plus some additional cached items, depending on expiration. I think that'd be reasonable here. And read items could even be hidden, shown in a separate view, etc., for the same effect.

In any case I think we can handle feed keys the same way we handle userID/localKey. We would assign a local key that would get converted to user-global key upon sync.

I don't think that part is the issue. Assuming feeds are associated with user/group libraries, the local key for URIs would be taken care of by the user library URI prefix (and that would be the only library you could associate with a feed before syncing).

Before we decide on URIs, we have to decide on some more fundamental things about feeds and other subscriptions. (We should assume that there will be other subscription types — for example, read-only subscriptions to specific collections in people's Zotero libraries, or other external-API-based subscriptions — that will be treated in more or less the same way, though maybe without read state.)

1. Do all subscriptions belong to the user, or can they be created within groups? The latter implies a shared read/unread state. Is there a use case for that?

2. Should users be able to organize subscriptions into containers of some sort?

3. If so, are they grouped into regular collections within libraries (which, somewhat strangely, could also contain local items), such that you could have a collection for a particular project and keep related subscriptions in the same collection? Or would they go in new "folder" objects — which would probably belong only to a user and be displayed outside of the user/group hierarchy — that could contain other folders, certain kinds of libraries (feeds, subscriptions), and maybe searches (which could even search across libraries) but not individual items?

For 3, collections would be more flexible, but it would mean you could end up seeing local items and feed items together in the same view (assuming recursive item display), and it would imply subscriptions within group libraries, which I think may be overkill. I can imagine a team that wanted to share responsibility for triaging feeds, but that doesn't seem very common — it seems more likely that shared read state would just be annoying. (Clients would fetch at different times, so you could end up fetching a feed and having everything already be marked as read.)

So I think my answers are 1) user, 2) yes, and 3) folders.

[aurimasv]

I don't think we need/want to sync individual items, though — that's a significant additional syncing burden for something that each client (even the website) could easily fetch independently.

Agreed

I also don't think we need feed item deletion, let alone syncing of it

Without explicit feed item deletion, I agree that there's no need to sync deletion state. I don't have strong feelings about being able to delete items, but I think some people will want to keep libraries/feeds clean. Oh well.

Do all subscriptions belong to the user, or can they be created within groups? The latter implies a shared read/unread state. Is there a use case for that?

That's an interesting thought. My initial take on this is that a collection of feeds would be for a user only, but I can think of situations where an organization or a group of people may want to provide a collection of feeds for their users to follow. So in that light, I think it would be cool to have feeds associated with group libraries. I do not think that it makes sense to share a read/unread state in those cases, though the read/unread state should still sync for any given user.

Should users be able to organize subscriptions into containers of some sort?

I think we were not going to worry about this initially, but in the long run, I think that's desirable.

are they grouped into regular collections within libraries (which, somewhat strangely, could also contain local items), such that you could have a collection for a particular project and keep related subscriptions in the same collection?

No, I don't think so. I think we need to maintain separation between items that were explicitly added by the user vs items that were automatically pulled from a feed. People like to keep their libraries neat and they want to know what's in them. This would be quite chaotic. For one, if the feed items are already displayed next to other library items, the user might expect them to persist, but instead they would be purged after a set amount of time.

Or would they go in new "folder" objects — which would probably belong only to a user

Yes. I think. Though if we go with group feeds, the organization should be shared... maybe.

be displayed outside of the user/group hierarchy — that could contain other folders, certain kinds of libraries (feeds, subscriptions), and maybe searches (which could even search across libraries) but not individual items?

Hmmm. Sounds a bit complicated to me. So going with the idea of group feeds, I imagine that we would display those under each group and user feeds would be displayed outside of "My Library". I guess we could stuff them under "My Library" though I don't personally like that. I was going to suggest that we could pull feeds from group libraries and replicate them next to user feeds, so they are easily accessible and so that the user can organize them. However, I think it would be better for user to transfer the feed from group library to his/hers personal feed collection. This way, if a feed is removed from a group library, it does not disappear unexpectedly from the user's feed collection.