[Owncloud] openPhoto integration with owncloud and SoK

[Michiel de Jong]

Hi!

On Thu, Apr 26, 2012 at 9:26 PM, Jaisen Mathai <jaisen at jmathai.com> wrote:
> - add in the OAuth dialog in the setup process
> Look at the Dropbox flow as it has an oauth step in there. It might be messy
> to include this in the setup controller since it wasn't planned to handle
> this but once it's working it's easy to refactor.

Yes, the way i did it is basically the same as with Dropbox. It means
there can only be one user (i.e. one storage backend) per OpenPhoto
server instance, correct?

> - not only push to remote storage but also pull from there if updates happen
> That's an awesome feature. The way we've typically handled this type of
> "extra" functionality is by having a separate repository for it instead of
> building in "polling" scripts into the frontend repository. Thoughts?

unlike the current remoteStorage spec, the new one (which we're
introducing over the next few months) support directory listing with
timestamps. So it's easy to poll the directory listing once a day, and
make sure the storage is in sync. detecting new photos in real-time is
a different matter, that's a bit harder. I think Dropbox recently
introduced a changes feed, and CouchDB has always had it (Max Ogden
calls it a SLEEPful API https://gist.github.com/1246804 ), but i'm not
sure whether reporting notifications should be a sine-qua-non
requirement on a 'dumb storage'.  We're also thinking about WebSocket
hubs to enable real-time notifications between apps or app instances
that collaborate on the same data, but this is all still in a research
stage. What do you mean by 'having a separate repository'?

> - make OpenPhoto serve the photos directly from remote instead of from local
> fs
> Are you sure you want to do this? I only ask because OpenPhoto generates N
> number of lower resolution photos for viewing on the web and mobile devices.
> Do users really want all these copies in their remote storage? I see these
> low resolution version files as simply for the sake of working on the web
> but otherwise provide no additional value to the user. Also, since they are
> low resolution they don't take up much space at all (so the local FS doesn't
> need to be huge). My perspective is that the originals are what need to
> remain in the user's control...especially considering the low res photos can
> be reproduced easily.
>
> - get rid of local file system dependency
> See above.

i prefer to have all data on my remoteStorage, and nothing on other
servers. we're adding mime-types to the remoteStorag standard, so that
resources can be directly server from the storage, and it becomes a
webserver in the sense of w3c's "read-write web" vision. in fact, i
would like to also have the MySQL database replaced by something that
is stored on remoteStorage. That way, web apps similar to OpenPhoto
can be written in javascript as an unhosted application rather than a
php/hosted one. if people want to use remoteStorage only for the
originals and not for the other versions, then we can make that
configurable. but by default i would prefer to separate storage from
application as much as possible. does that make sense?

I have the basics more or less working now, although there is still
enough to do to fill a summer of hacking. Right now i'm figuring out
what to do if the remoteStorage reports an error like 'access token
expired' or 'photo too large'.

Shivani, Jatin, you expressed interest. Do you want to jump in? I
don't know how that would work with ownCloud's SoK program, but on the
code side, i would be very happy to help with whatever is needed. As I
already told Jatin, the Unhosted project can also sponsor a
development server for whoever wants to work on this.