Re: GSOC 2011

[Sven Utcke <sven utcke gmx de>]

Hello Simon,

> > > 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.

Hmm.  I assumed that files would be stored offline too (and therefore
always reachable under the same URI), and at most a local copy would
be kept (which would be found in a completely different way anyway,
maybe along the lines of locating thumbnails...)

> > 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...

Why?

> > > >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 :)

Ok, I can agree with that.  And yes, I too do know people who store
metadata in their files, some of them even are my friends (and I'll
admit that once upon a time I too was tempted by the dark side :-)

> > > >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.

Then you've got better ping values then I have :-)  Let's just say
that it will probably result in quite a bit more overhead.  And at
least on startup you probably will query Metadata for _all_ images
(not sure how F-Spot handles that now, but I would think so).

> > > >  * 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. 

Well, yes.  Ok, sort of.  If I understand the thumbnail mechanism
correctly, it can generate thumbnails not just for local files, but
for any URI it understands.  Of course it needs to download the images
for that (once), but that would be true for any approach, always...

> Anyway, I don't think I'll have time to implement partial caching.

Just think about what this would mean for your use-cases.  Maybe
that's fine, don't know...

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

Better according to what metric?

Sven
-- 
  __ _  _ __  __ __ 
 / _` || '  \ \ \ /                                   http://www.svenutcke.de/
 \__, ||_|_|_|/_\_\                                    http://www.dr-utcke.de/
 |___/     Key fingerprint =  6F F8 55 1C F9 E3 A8 F7  09 DF F7 2C 25 0C 54 53