RSS/Atom feed

[hfiguiere]

We need to provide RSS/Atom feed for:

-last upload -tags (in upload order)

etc.

[hfiguiere]

Instead of "list" or "view" we do "rss" or "atom" in the endpoints

[hfiguiere]

Feed for photo (global, by tag, etc) Feed for comment per photo Etc.

[jmathai]

Actually, we should add the extension to the endpoints. This is how the API works and we can keep it consistent.

• /photos/list.rss
• /photos/list.atom
• /photo/:id/view.rss (for comments?)
• /photo/:id/view.atom

[michelv]

Is anyone working on this, or can I have a go at it?

[jmathai]

No one's taken this on yet. It's all yours :). Let me know if you have any questions.

[hfiguiere]

Awesome !

I unassigned myself. But I couldn't assign to @michelv .

[jmathai]

@hfiguiere It's coz the assignee is a bit broken IMO for Github issues. They have to be members of the project to be able to assign. Doesn't make a lot of sense for open source projects like this.

@michelv is this something you're willing to take on?

[michelv]

I have started work on this last night for an hour actually, so I'd really like to make it a proper contribution to the codebase.

What I have right now:

• routes-feed.php file that, as the name implies, defines routes for feeds, with /photos/list.:feedformat and /photo/:id/view.:feedformat
• FeedPhotoController that handles the aforementioned routes
• feed-atom.php and feed-rss.php files that can be overridden by theme authors (for example if they want to customize feed items with trackers and other things)
• [feed] section in config that defines pageSize (default 20) and photoSize (default 800)

A list of hurdles that I have met so far:

• to reference the URLs to feed items, I need a base URL for the site; this is not defined anywhere in the codebase, unless I missed something
• I haven't fully grasped how route arguments are passed to controller methods, so I'm either getting the :feedformat part with func_get_args() or specifying as second optional argument with a default of 'atom'. Surely there is a better way? (Haven't checked how it's done in other controllers yet though.)
• the feed-(atom|rss).php part is not ready yet, I couldn't find how to display them when they're only in src/templates and not in themes dirs
• haven't checked caching yet (304 etc)

If I can be solve these quickly, there could be a pull request within the week. :)

[michelv]

For the base URL, I added a setting for [site], "baseUrl". When not set, the code could use the requested hostname.

For caching, it seems like there is none anywhere in the app?

@jmathai, @hub: for demo purpose, here's my current Atom feed: http://photos.miche.lv/photos/list.atom

[jmathai]

@michelv Awesome. Are you able to submit a pull request? If it's not 100% ready that's no problem as we can work through it pretty easily.

[alpha1]

Is this still active? If not i'd be interested in working on it.

[jmathai]

We probably want to look at a proper RSS/Atom library. The first one I came across was this one. http://www.phpclasses.org/package/4427-PHP-Generate-feeds-in-RSS-1-0-2-0-an-Atom-formats.html

[jmathai]

@michelv What's the status on your fork and where can @alpha1 pitch in?

[michelv]

Hello,

I would produce a pull request, but it's blocked by refactoring work that needs to be done in the MySQL adapter.

The problem is that we want to sort photos by "dateUploaded,desc", but in buildQuery() this gets transformed into "dateSortByDay DESC, dateUploaded ASC".

I think the MySQL adapter should not be the place where such transformations occur, because it makes the rest of the codebase counter-intuitive to read or author in the future ("oh I want to sort by day then by ascending upload time, I'll use a sort by upload time descending then!").

If we can have a cleaner handling of the sortBy option, then the rest of the work is straight-forward.

Moreover, maybe the approach needn't be to produce a feed of photo items, but of activity items? We could then have a feed of 50 items where, if I upload 2 pictures, then 100 pictures, the first two are still visible to feed readers.

I don't think feed producing libraries add anything interesting to the project. A feed is just another template. If we have it that way, users could customize their feeds by editing the feed template files; whereas using a feed producing library the work would be abstracted away and more difficult to customize.

[jmathai]

I completely agree...but it's complicated. I'm not sure we can move the sort logic outside of the database adapter. The database (usually) is optimized to do the sort. If we move it out then we have to always return a full dataset and then sort it in PHP land. That could get to be slow with users that have lots of photos (>20k?).

@garethgreenaway had to do this in the DynamoDb adapter he was playing with. Not fun.

I'm proposing several predefined sorting options and implementing those in the database adapter. Probably no more than 3 + asc/desc.

• dateUploaded DESC
• dateUploaded ASC
• dateTaken DESC
• dateTaken ASC
• natural DESC
• natural ASC

[alpha1]

Here's my thoughts. Your going to usually be uploading many pictures (An "Album") at a time. Each feed item should be one album. Display the top 10 most recently updated albums, generating the new rss feed on completion of the upload.

The feed could contain the whole album, just the first image, or a select number, say up to 5 images.

if you created the feed on upload, im not sure you would need another set of mysql commands?

[jmathai]

There's an activity API which is essentially a feed. If it's useful. http://theopenphotoproject.org/documentation/api/GetActivities

[michelv]

@jmathai I suppose "natural" sort in this case is sort by day desc then upload time asc, which is the current sort option on the gallery page?

That would solve most of the current annoyance of modifying valid sort options in database adapters.

It's a step in the direction of having abstract sort options: this way, if you really want to sort by "dateUploaded DESC", you really do.

As for the activity API, this is exactly what I aimed at. I'll work on feeds using the activity API this weekend.

[jmathai]

Tracking the sort options in issue #735.

[michelv]

I just sent a pull request: https://github.com/openphoto/frontend/pull/771/files (Sorry for the delay, I eventually had a lot of things to do IRL that left me very little time to code.)

[jmathai]

Looks good. On first glance the only thing I'd change is the URL to the feed to be /feed/activity/list.json. And there were some changes to the autoloader since you pulled but that's only in the development branch. Easy for me to resolve. Great PR :). Pull request, not public relations.

[michelv]

I forgot to ask earlier: would you prefer PR to be done on the development branch instead of master? (I tend to use master because my working directory happens to be a live install, but I could rebase and test on development branch quickly before sending my branch.)

[jmathai]

That'd be ideal but not necessary. I'd merge it into the development branch either way. You can try the rebase if you want but if you get conflicts or anything then don't bother :). We added an autoloader which might create a conflict...but give it a shot :).

[michelv]

Just added some comments on my pull request to highlight parts that need more work before they can be merged.

[michelv]

OK, then I'll let you handle the conflicts. :)

[arthurlutz]

has this been merged ?

[jmathai]

@arthurlutz I believe there are a few outstanding issues before it can be merged. So, not yet.