Open hfiguiere opened 12 years ago
Instead of "list" or "view" we do "rss" or "atom" in the endpoints
Feed for photo (global, by tag, etc) Feed for comment per photo Etc.
Actually, we should add the extension to the endpoints. This is how the API works and we can keep it consistent.
Is anyone working on this, or can I have a go at it?
No one's taken this on yet. It's all yours :). Let me know if you have any questions.
Awesome !
I unassigned myself. But I couldn't assign to @michelv .
@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?
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:
A list of hurdles that I have met so far:
If I can be solve these quickly, there could be a pull request within the week. :)
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
@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.
Is this still active? If not i'd be interested in working on it.
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
@michelv What's the status on your fork and where can @alpha1 pitch in?
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.
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.
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?
There's an activity API which is essentially a feed. If it's useful. http://theopenphotoproject.org/documentation/api/GetActivities
@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.
Tracking the sort options in issue #735.
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.)
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.
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.)
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 :).
Just added some comments on my pull request to highlight parts that need more work before they can be merged.
OK, then I'll let you handle the conflicts. :)
has this been merged ?
@arthurlutz I believe there are a few outstanding issues before it can be merged. So, not yet.
We need to provide RSS/Atom feed for:
-last upload -tags (in upload order)
etc.