On Mon, 6 Jul 2020 12:55:28 +0200
Torstein Eide wrote:
> Yes I think the proposed design would work with local files also.
> There multiple ways to achieve this.
> option 1: add a new column in the database where you put "local", or
> "remote01"
> option 2: is a dedicated mode for remote stor
Yes I think the proposed design would work with local files also.
There multiple ways to achieve this.
option 1: add a new column in the database where you put "local", or
"remote01"
option 2: is a dedicated mode for remote storage where every local database
only works against one remote server
On lundi 6 juillet 2020 08:28:40 CEST Torstein Eide wrote:
> 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 clien
On lundi 6 juillet 2020 07:35:59 CEST Michael Mosmann wrote:
> Am 05.07.20 um 23:02 schrieb Guillermo Rozas:
> > Really, the best option now is the local copies feature. Anything else
> > is fighting against the way darktable is designed to work (as a
> > standalone local application). You can do i
Michael Mosmann schrieb am 06.07.20 um 07:35:
Is there some information which is not stored in image metafiles and
only stored in the local darktable db?
yes, grouping e. g.
--
regards
Bernhard
https://www.bilddateien.de
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
Am 05.07.20 um 23:02 schrieb Guillermo Rozas:
> Really, the best option now is the local copies feature. Anything else
> is fighting against the way darktable is designed to work (as a
> standalone local application). You can do it, but, as they say, "you can
> keep the pieces when you break it".
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 hu
On Sun, 5 Jul 2020 14:50:45 -0300
Guillermo Rozas wrote:
>
> 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
>
> Would there be any problems created during an update? ...
>
Yes, specially with the git version you risk having incompatible versions
of the database between different installations. At best, it would prevent
you to work until you update, at worst it could corrupt the database.
> Would latency
I run dt on multiple machines (in multiple locations), I update the Arch
systems with the latest git on a very regular basis. The suggested idea
of using an external dive for the imagery and config files is appealing.
# darktable --configdir "/path/to/server/config/darktable" --cachedir
"/path
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
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 b
>
> While this is a real need, someone's genuine desire, does it have to be
> part of Darktable, or could it be a separate piece of software that
> darktable plays well with?
>
At some point you need to modify something in darktable's code, because
darktable accesses its databases directly, and as
>
> 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 S
* Guillermo Rozas [07-05-20 13:39]:
> >
> > It is a regular topic of conversation, along with related DAM matters.
> > However, there isn't really a spec for what is needed/wanted, nor is anyone
> > stepping up to write such a spec, or design and implement a solution.
> >
>
> I would say DAM feat
>
> It is a regular topic of conversation, along with related DAM matters.
> However, there isn't really a spec for what is needed/wanted, nor is anyone
> stepping up to write such a spec, or design and implement a solution.
>
I would say DAM features are more important, and probably more widely
n
While this is a real need, someone's genuine desire, does it have to be
part of Darktable, or could it be a separate piece of software that
darktable plays well with?
I hope the latter. I would suggest that the addition of more and more
functionality to Darktable, outside of the core mission, may
I will likely face the same question in the near future. Few thoughts...
If I understand correctly - SQLite won't work well in a client / server mode
https://stackoverflow.com/questions/1321493/sqlite-for-client-server
One of the channels I am watching discussed "syncthing"
https://youtu.be/O5
It is a regular topic of conversation, along with related DAM matters.
However, there isn't really a spec for what is needed/wanted, nor is anyone
stepping up to write such a spec, or design and implement a solution.
On Sun, 5 Jul 2020 at 14:53, Guillermo Rozas wrote:
> I would love and support
>
> I would love and support a concept of server/client for darktable.
>
The best way to ask is to do that in Github (
https://github.com/darktable-org/darktable, create a new 'Feature request'
after checking it was not asked before).
I'm not a developer, but I would expect not to be an easy thin
Thanks, Bernhard, Rene and Guillermo.
So currently the safes approach is to use local config, and maybe have
the cache on the NAS.
Since if I were to have the database on the NAS as well I may run into
issues, i wanted to work remotely with my photos.
I would love and support a concept of server/
Not in an easy way, there is no concept of server/client for darktable. In
particular, sharing the library between computers is prone to generate
problems.
In principle, all of darktable's configuration and libraries are saved in a
couple of files, so you could share those files between installati
On 05/07/2020 14:43, Bernhard wrote:
Torstein Eide schrieb am 05.07.20 um 14:36:
Hi
Is it possible to set up darktable in a server/client mode? Where I
have all my files and setting on server. But I can access the same
library from different client machines.
if you are only one person usi
Torstein Eide schrieb am 05.07.20 um 14:36:
Hi
Is it possible to set up darktable in a server/client mode? Where I
have all my files and setting on server. But I can access the same
library from different client machines.
if you are only one person using one machine at a time you might se
Hi
Is it possible to set up darktable in a server/client mode? Where I have
all my files and setting on server. But I can access the same library from
different client machines.
darktable user mailing list
to unsubscribe
26 matches
Mail list logo
