Re: GSOC 2011

[Simon Lindgren <simon n lindgren gmail com>]

mån 2011-03-28 klockan 13:18 +0200 skrev Sven Utcke:
> 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?

My bad. I based that comment on the incorrect assumption that the URI
would point to (or at least use) a locally mounted filesystem.

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

Well, I forgot to account for roundtrip latency... Which is also why I
wrote "Generating...". Ping across the atlantic lands at 30-200ms for
me.

And my current thinking is that the other parts of F-Spot will continue
using the local SQLite database. The syncing runs in the background
without disturbing the user (unless there is a conflict). Though I'm not
sure how the rest of the F-Spot code will react to that kind of
treatment, it is possible that approach is hard to implement well in the
current F-Spot codebase.

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

What about the case of not generating the thumbnails using the regular
mechanism? From what I understand this is a step backwards (so it's
probably not an awesome idea), but applications can save thumbnails to
the user-wide thumbnail cache themselves, so theoretically they could be
fetched from the server, saving loads of bandwidth. Still, probably more
trouble than it's worth.

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

I think I could tolerate it, but it would be a nice thing to have
anyway, and it might be a requirement for other people too.

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

Better as in "not a thread on some mailing list somewhere" ;)
Draft 1 in the other mail you responded to.

-- 
Simon Lindgren