[Shotwell] mysql/postgresql as backend?
adam at yorba.org
Fri Apr 30 12:15:27 PDT 2010
thanks for your latest message. We're also very interested in extending
Shotwell to sync and/or share photos, either across a local network or
across the Internet. Of course there are many possible mechanisms we
could use to do this - conceivably we could use a database file which is
shared across the local network using file sharing (as you suggested),
or a server, or peer-to-peer syncing, or some sort of distributed
database system. We're as yet undecided about which mechanism to use.
None of this will be in the upcoming Shotwell 0.6, but we hope to
implement some sort of sharing/syncing in the future, perhaps even later
this year. See these tickets:
http://trac.yorba.org/ticket/1292 (share/sync photo library between
http://trac.yorba.org/ticket/1572 (Shotwell Server)
On 04/30/2010 05:48 AM, Bengt Thuree wrote:
> Yes I can see that this ticket (D-Bus) would solve some issues.
> But not the one with a family and a number of computers.
> For instance, I am updating the photos from my laptop (connected to our
> file server), while my wife is looking at the old photos (again, through
> our file server) as well as possible publishing some photos or modifying
> some tags/ratings here and there.
> This would not be possible with sqlite as far as I am aware (single
> program who reads), but very possible with a sql backbone.
> Perhaps a function that informs all other connected clients to re-read
> part/all of the database?
> While on the subject of family :) Perhaps a locking feature, to ensure
> children can not modify any photos/tags :)
> On Wed, 2010-04-28 at 10:41 -0700, Jim Nelson wrote:
>> We've thought down these lines, but it's not as simple as it seems.
>> The database is not used by Shotwell in a traditional sense, a la a
>> web application. If we hit the database every time we needed
>> information about a photo or a tag or an event, Shotwell would be slow
>> indeed. This is not a limitation of SQLite; using MySQL or PostgreSQL
>> would not make things different.
>> Much of the database is loaded into memory at startup and maintained
>> there. When a field is changed, it's written out to disk, but kept in
>> memory as well. If another application were to write to the database
>> while Shotwell was running, Shotwell would have no idea the change has
>> been made, and now things are messed up.
>> Some of this thinking is reflected in this ticket:
>> http://trac.yorba.org/ticket/1699 There's a lot to think about there,
>> -- Jim
>> On Wed, Apr 28, 2010 at 7:39 AM, Bengt Thuree<bengt.thuree at gmail.com> wrote:
>>> Any thoughts/plans on coming up with a proper backend, so the database
>>> can be accessed by different persons at the same time.
>>> I saw GnuCASH is using libdbi. Would this be of interest in Shotwell?
>>> In my case, I have a number of desktops/laptops/thin clients, and one
>>> fileserver. I am having the photos and photo db on the file server, and
>>> would like to be able to access my photos from which ever computer I
>>> want, as well as from multiple computers at the same time.
>>> Fingers crossed for this has been thought of :)
>>> Shotwell mailing list
>>> Shotwell at lists.yorba.org
> Shotwell mailing list
> Shotwell at lists.yorba.org
More information about the Shotwell