On Tue, 2009-05-12 at 13:35 -0400, Daniel Falk wrote: > > Again, if you're going to allow for a good multi-user experience, Yes, multi-user, not remote use experience. > you're > almost certainly going to have to redesign key parts of f-spot. I don't think it's as difficult as you are making it out to be. Certainly not if you don't include the other pet features you want to see. > While you're right that the features > I've described are different, they are related in that the redesign > should probably take all those possibilities into account in order to > avoid further disruptive redesign. Perhaps not though. The problem is that you are striving for perfection and many times perfection is the enemy of progress. Too many projects die in progress because they strive for perfection and just run out of steam rather than striving for reasonable progress. > I'm just saying that I think this feature is part of a larger problem. > Believe me though, I agree that it would be an awesome thing to solve. > I would just hate for it to get solved in a shortsighted way. The alternative is that the much bigger solution is too big and adventurous and so nobody takes the adventure and we remain stifled and get nowhere. > It's not just the database. I would think you would want to be able to > notify other clients that things have changed...basically have an > event-managing component. Locking (which I discussed in my previous message) is frequently used for this messaging. "Changed" is only an issue for clients which have a copy of something, which only remains valid for as long as the client can hold a read lock on the object. For example, a client takes a copy of some object that is available for reading (i.e. not write locked) access. The client takes out a read lock and holds that lock while he has the cached copy of the object. If another clients wants a read copy, no problem, he holds a read lock as well and keeps a copy while he has the read lock. If a third client wants to write to the object, he takes out a write lock and the read locks of the first two clients are revoked and that revocation is their signal that the object is being modified and they should purge their local copy. As for f-spot UI, perhaps at that point f-spot puts up some "being modified" type icon in place of a photo. As soon as their read locked are revoked (by the writing client), the clients that want to have that read-only copy try to re-acquire their read locks and are put on hold while the writer finishes writing. When the writer is done, the write lock is revoked allowing the read locks to progress and the clients are signaled that their read locks have been granted and they re-read the object, getting the update. This is why I wondered about locking in sqlite. b.
Attachment:
signature.asc
Description: This is a digitally signed message part