I would agree that latency is not a problem. I don't think the server side need to handle all work that the client does. The client should only periodically send changes to the server database, as a background task. So I think client still need a database, but with a server that handles the storage/backup/config.
the client database can be more lightweight, and easyer to get a new client up and running. man. 6. jul. 2020, 07:49 skrev Michael Staats <michael.sta...@gmx.de>: > On 05/07/2020 23:02, Guillermo Rozas wrote: > > > Would latency be a significant problem? > > > > darktable needs to access its databases for every single edition. Every > > time you change a parameter on a darkroom module this gets written to > > the library database. So I would say latency would be a huge problem. > > Hi > I do not think that latency is any problem, as long as the DB is > accessible via a "reasonable" network link and the DB is not on a > completely overloaded server. > Much more complex applications based on a "three tier" architecture do > exist (end user application/GUI, server application, database), and they > can handle thousands of users in parallel. Ok, they run on powerful > server hardware, but for dt, you would only have a few users working in > parallel. > > And not only your enterprise resource planning tool works like that. I > have managed e.g. the Tivoli TEC, and an event management system using > Oracle or DB2 as backend, and the number of events it could handle was > pretty high (although we sometimes had issues, but that was with > thousands of events per second). This was at the beginning of the > millennium, nowadays your dt desktop has more CPU and memory than the > IBM RS6k we had at that time. > > Nevertheless, it would be a major effort to modify the dt "package" to > work with a proper DB server, no matter which. And stability for the end > user would certainly suffer, to say the least. Who will support the DB > server? This cannot be expected from a desktop user whose focus is on > raw development, not IT. > If at all, it would have to be an option to use a DB server, not the > default. The implementation is a lot of work, and I agree with others, > I'd like to see these efforts going into the core functionality of dt. > > In any case, just if someone tries: Why is everybody thinking of > MySQL/MariaDB first? I think they still do not implement a proper > transaction handling (e.g.: constraints are checked when running one > statement, not at the commit. This makes certain things impossible... > This is only one example, maybe they fixed it, but what does it tell us > that it even existed?). > postgres would be a much cleaner implementation. > But maybe an SQL based relational DB is not the best choice anyway. What > about mongo? Might be more appropriate, but implementation requires even > more effort on the dt side... > > My summary: Nice to have, but with limited resources, I'd prefer to > improve the core of dt. > > Only my 2 cents, best regards, > Michael > > > -- > Michael Staats > michael.sta...@gmx.de > > ____________________________________________________________________________ > darktable user mailing list > to unsubscribe send a mail to > darktable-user+unsubscr...@lists.darktable.org > > ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
