<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi there,</p>
<p>based on the welcomed straight answers <span
class="moz-smiley-s1"></span> in regard of feature dev in <a
href="http://digikam.1695700.n4.nabble.com/digiKam-users-either-face-recognition-screen-is-buggy-or-I-still-don-t-understand-it-at-least-I-can-8-tp4705248p4707753.html">[digiKam-users]
either face recognition screen is buggy or I still don't
understand it...</a><br>
</p>
<p>there are only two options:</p>
<ol>
<li>get it added to <a
href="https://community.kde.org/GSoC/2019/Ideas#digiKam">GSoC/2019/Ideas
- digiKam</a> <br>
</li>
<li>dev it yourself or find some support, respectively<br>
<blockquote type="cite"> ...i'm always in favor to only use
bugzilla as the main Agile project management tool. You have a
file to create or already created, you build a patch against
current implementation, and you attach file. It's simple,
archived, and follow all QA requirement.</blockquote>
@Gilles:</li>
<ol>
<li> is there any space where some idealist could find each
other and try to do so under your supervision</li>
<li>could you tell where to there right spot in the source code
for such enhancement?<br>
</li>
</ol>
</ol>
<p>here are the clarifying statement about the near future of
digiKam <br>
</p>
<p> </p>
<blockquote type="cite">
<div>No. Personalty, i must for 6.1.0</div>
<div><br>
</div>
<div>1/ Finalize the internal plugins API for Genric, Editor, and
BQM.</div>
<div>2/ Document the API</div>
<div>3/ Export the API for external contribution. Currently all
plugins are inside digiKam project.</div>
<div>4/ Prepare the rooms for the new students.</div>
<div><br>
</div>
<div>Later 6.1.0 :</div>
<div><br>
</div>
<div>1/ Prepare new plugins interface as :</div>
<div>...</div>
<div> * Database : We have already a tool named migration which
can be a good candidate, but plenty of new ones can be written :
backup, export, etc. Do not ask me to make the database engine
as module yet, it's a tedious project.</div>
</blockquote>
<br>
<p>Stefan</p>
<div class="moz-cite-prefix">Am 27.01.2019 um 22:47 schrieb Leo
Gaspard:<br>
</div>
<blockquote type="cite" cite="mid:877eepydr8.fsf@llwynog.ekleog.org">
<pre class="moz-quote-pre" wrap="">Hey Stefan,
Thank you! Indeed, the idea of writing all metadata to files is, I
think, much better than what I had in mind! It'll both avoid the MySQL
roundtrip for the database (while still keeping it for the actual
pictures it'll at least allow to get fast thumbnails, even if the
full-quality picture takes more time to load) and digiKam
synchronization errors (though now to update other people's picture
databases one would need to do it manually, and it'll likely be slow
over WebDAV, but at least it'd work).
I'll be reporting here as soon as I get results, hopefully soon!
Cheers,
Leo
"Stefan Müller" <a class="moz-txt-link-rfc2396E" href="mailto:stefan.mueller.83@gmail.com"><stefan.mueller.83@gmail.com></a> writes:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hoi Leo,
are still following the original thread?
Your are not the only one who thinks about Multi-User environment, see digiKam Bug List Component:
Database-Multiusers Product: digikam Status: REPORTED, CONFIRMED, ASSIGNED, REOPENED
I reckon those are the most recent discussion in this matter:
* Multi-user with mysql server
* [digiKam-users] Multi-user digiKam setup?
* [digiKam-users] Use digiKam with a NAS and MariaDB
* [digiKam-users] temporary port photos and metadata from MariaDB/network share for editing when offline /
being on the move
* Wish 401622 - Simple multi-user, to start with
* Wish 254099: SCAN : refresh collection with a script in commandline
Does those ideas/approaches matches/supports your suggestions?
Stefan
Am 26.01.2019 um 23:31 schrieb Leo Gaspard:
Oh. So even the MySQL database backend doesn't support concurrent use?
That'll make things harder…
Anyway, thank you for your comment! I haven't really found anything that
appears to handle this use case better than digiKam, so will report here
if/when I get something working! With chat-based end-user-level database
locking, for the time being :)
Cheers,
Leo
Gilles Caulier <a class="moz-txt-link-rfc2396E" href="mailto:caulier.gilles@gmail.com"><caulier.gilles@gmail.com></a> writes:
Le sam. 26 janv. 2019 à 02:13, Leo Gaspard <a class="moz-txt-link-rfc2396E" href="mailto:digikam-users@leo.gaspard.io"><digikam-users@leo.gaspard.io></a> a
écrit :
Hello,
I'll try asking just one last time, by decreasing order of importance:
* Is digiKam not unbearably slow when the pictures are on a WebDAV and
the database a remote MySQL?
The Webdav storing was never tested here, at least be me.
The network is the bottleneck here. Mysql thumbnails storing is the part
which use the network bandwidth a lots. With 6.0.0, Maik has optimized the
network use with Mysql.
* Does putting the digiKam database in MySQL put the WebDAV password in
the MySQL?
No idea...
* Does digiKam work properly with collections on read-only filesystems
and especially read-only WebDAV?
Read only is not a problem is you don't want to change the files data.
* Does anyone have any feedback about sharing a digiKam database with
other people (and not only other computers from the same person)?
This kind of workflow is not implemented yet... You can only sync the file
metadata with database and sync back a remote storage. It's so far not
optimal.
In all cases the database do not contains yet the guards for concurrent
uses.
Gilles Caulier
(more details in the quote below)
Cheers,
Leo
Leo Gaspard <a class="moz-txt-link-rfc2396E" href="mailto:digikam-users@leo.gaspard.io"><digikam-users@leo.gaspard.io></a> writes:
Hello world!
I have tried IRC to bother the fewest possible people, but it looks like
#digikam@irc.freenode.net is dead, so let's try here. Sorry for the
noise!
I am considering using digiKam, but as my use case is kind of peculiar,
I thought I would first ask whether you think I have chances of
succeeding at what I'm trying to do.
Context: I'm trying to setup a shared photo database with my family for
all our photographs. Photos will be shared over NextCloud, and hopefully
digiKam would be used to both tag them and synchronize the tags. Now,
the photo database is kind of huge, and not all computers are able to
download it in full. In addition, not everyone has the same taste for
photos, so I think it'd be better if everyone only had write access to
their own directory, and read access to others'.
My currently imagined solution:
* Each user puts their pictures in their write-for-them read-for-all
folder in Nextcloud
* Everyone runs a digiKam instances. Tags are synchronized either
through MySQL or by just adding the SQLite database to the Nextcloud
* digiKam is setup to directly fetch the photos from WebDAV from the
Nextcloud instance
So my questions are:
1. Do you have advice on whether to pick MySQL or synchronize the
SQLite database over Nextcloud? (I will have linux, windows and mac
clients) Will sharing the database not risk sharing the WebDAV
credentials?
2. Does digiKam handle well-enough collections on read-only folders?
3. What do you think about the overall idea?
4. Bonus question: Ideally users could also have their own private
databases that are not shared. Does digiKam handles properly
switching between two databases, ideally with one that includes the
other?
5. Trick question: If an answer is no, is there any project other than
digiKam that could handle these requirements and that you would know
about?
I've searched a bit the manual and didn't find much about these
questions, and I must say I'd rather request an opinion from someone
knowledgeable before starting the setup, that will likely be kind of
long and complex, especially if done with MySQL. Sorry if the questions
are already answered someplace I didn't find!
Cheers, and thank you for digiKam that looks like some nice piece of
software!
Leo
</pre>
</blockquote>
</blockquote>
</body>
</html>