My first thoughts about architecture is the following: # Server:
- Provides an API to the Client. - Is the only direct user of the database, so SQLite will still work, but Mysql/MariaDB is much faster. - Have a web interface for management. - User upload images via API or web interface- - Server is responsible for generating thumbnails. - Server is responsible for handling storage of images. # Client: - Access the server via API. - Downloads thumbnails for faster browsing. - Download to local cache any images for editing. - Client adds new files to local cache first, then uploads in the background to the server. Alla OwnCloud. Since I don't know all the inner workings of darktable there is probably internal service I have skipt. søn. 5. jul. 2020 kl. 20:08 skrev Remco Viëtor <remco.vie...@wanadoo.fr>: > > On dimanche 5 juillet 2020 19:50:45 CEST Guillermo Rozas wrote: > > > If I understand correctly - SQLite won't work well in a client / server > > > mode > > > > > > https://stackoverflow.com/questions/1321493/sqlite-for-client-server > > > > In the case of darktable the problem described there (performance because > > of simultaneous access) won't be a big issue. The problem is that SQLite > > doesn't have the access locking and multi-access control baked in, you need > > to code your own database server that includes those features. So it won't > > be as simple as saying "let multiple instances access the library", there > > must be a middle-program written for it. > > > > You could use another database format, like digiKam that has MySQL support > > (optional and experimental), but then the user needs to provide its own > > MySQL server, so it's not 'easy' to use. > > > > > It may be an approach to go around with synchronizing the DB on 2 or > > > more machines (I haven't tried it actually) > > > > You can certainly do that, but you will still have the same problems I > > described before (probably worse because syncing is real time in this > > case). The problem is not how do you share the databases, the problem is > > that you share them at all ;) > > Another problem is latency, whenever there's a network involved. That was a > recurrent problem for Digikam, even with MySQL, simply due to the amount of > data that had to be transported over a relatively narrow channel (compared to > local disk access). It wouldn't be that noticable when editing files one by > one, but using the DAM functions could be slow... > > Remco > > > > > ____________________________________________________________________________ > darktable user mailing list > to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org > -- Torstein Eide torste...@gmail.com ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
