Re: GSOC 2011

[Simon Lindgren <simon n lindgren gmail com>]

lör 2011-03-26 klockan 22:18 +0100 skrev Sven Utcke:
> Hello Peter and Simon,
> 
> > I think it's a worthwhile project, certainly.  I've dabbled with
> > F-Spot as a user, but I don't really use it.  However, if it were
> > cloud-enabled, I might be able to make good use of it.
> 
> That certainly would be a nice feature.  And most of it is actually
> already there!
> 
> > Another option, 3: Use a server-side SQLite
> > <http://www.sqlite.org/cvstrac/wiki?p=SqliteNetwork> instead of a
> > local SQLite.
> 
> This depends on the focus: if you can be sure to always be online,
> this is absolutely the way to go.  But what if you are in a place with
> limited internet access?

There is one more case against using a db server directly: User names
might be different on different machines. Currently the full path is
stored in the db, for example file:///home/simon/Images/...
This means some translation of the paths may be needed, or the schema of
the local database needs to change.

>   You would at least want to be able to load
> the images on your computer anyway, wouldn't you (of course you could
> just copy them someplace, then import later, when back online)?
> 
> > Then like #1, synchronize the picture folder on a file-by-file
> > basis.
> 
> Well, F-Spot already stores URIs, so all it needs is a way to access
> all desired URIs.  That ought to be fairly easy to add for at least
> the most common ones (html, ftp, maybe webDAV).  But there's again the
> problem that you might want to first store the pictures locally, and
> upload once connected.  Maybe you even want a local file-cache for the
> N most currently accessed files, for offline-editing etc?

And again the case described above...

> 
> > And a crazy (but cool) option, 4: use Flickr as the primary image
> > store.  Probably with a server-side SQLite to handle metadata, and
> > of course, local thumbs 
> 
> Thumbs are handled by Gnome and are always local anyway.  So as long
> as you assume an always online machine, a proof of concept
> implementation should need only a few evenings at most.  Wrapping that
> up nicely, of course...
> 
> > and optional synchronizing of local/remote full images.
> 
> Now, _that_ might turn out to be the real hurdle (but also the thing
> really needed)
> 
> > >1. Store all metadata inside the image files or as sidecars, and then
> > >   synchronize the picture folder on a file-by-file basis.
> 
> Storing metadata in files is evil :-)

I happen to disagree... at least I used to. Let's just say that it must
be possible to avoid it :)

> 
> > >2. Create a specialized server software to handle the metadata
> > >   syncing and file transfers.
> 
> This really ought to be able to work using just standard server
> software (REST, preferably).  Would be a bit on the slow side, but
> then, compared to _up_loading your images to the server trough the
> A(for asymmetric)DSL bottleneck, everything else will be greased
> lightning.
> 

Generating a REST response is unlikely to be slow unless the response is
all metadata for all the images or something similar... In general it
should be measured in the tens of milliseconds range. And, as you say,
upload bandwidth is going to be the limiting part anyway.

> > >  * Support downloading pre-generated thumbnails for a set of images.
> 
> Thumbnails are handled outside F-Spot.  Really.
> 

In general, I agree, but that stance also completely kills the idea of a
partial local cache of the fullsize images, because they would need to
be downloaded if the system is to generate the thumbnails. Anyway, I
don't think I'll have time to implement partial caching.

> > >So, are there any thoughts on this? Is it a worthwhile project?
> 
> If you manage something that does not need to be online all the time:
> absolutely!  That would be a fairly unique selling point.
> 
> If it needs to be online all the time: Well... 
> 
> But still, if it can use flickr and Co. (and, as I said, that ought to
> be dead easy --- maybe it can even now?), that still should buy you
> some goodwill from a lot of people (not me, though).

I think Conduit can do that. It has a F-Spot module and a Flickr module,
but the F-Spot one didn't work for me. I didn't really try very hard
though.

Anyway, I'm working on a better GSoC application, focusing on the
Client-Server approach and in fact also using REST :) 

-- 
Simon Lindgren