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 _______________________________________________ f-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
