[digiKam-users] Multi-user digiKam setup?
Gilles Caulier
caulier.gilles at gmail.com
Sat Feb 2 16:35:48 GMT 2019
Le sam. 2 févr. 2019 à 15:09, Stefan Müller <stefan.mueller.83 at gmail.com> a
écrit :
> Hi there,
>
> based on the welcomed straight answers in regard of feature dev in [digiKam-users]
> either face recognition screen is buggy or I still don't understand it...
> <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>
>
> there are only two options:
>
> 1. get it added to GSoC/2019/Ideas - digiKam
> <https://community.kde.org/GSoC/2019/Ideas#digiKam>
>
> If you add new ideas, we need someone to follow and mentoring the student.
Typically we work as double mentoring (main and alternative).
Following a student is time consuming, but can give good results if the
student work well. It's not always the cases, and this is why a selection
must be done well.
I'm already contacted by few students through Linkedin. I talk and try to
judge the skills through few some junior jobs. It's a take a while, because
a wrong selection can be catastrophic.
I already mentored a wrong selection, and at end, i re-write all the code
because student do not listen all my recommendations or do not respond.
Don't forget : with GoSC event, students will be payed, if they do the
engineering job. So, some people try to be connect to a project to at least
checkout so money without to do a real project.
Now, back to the GoSC idea. Why not, but we need help as main mentoring.
Time is limited for main mentors, don't forget this point.
>
> 1.
> 2. dev it yourself or find some support, respectively
>
> Find new contributors is fondamental to see a project alive in long time.
And there is not only c++ development to help in this project.
For ex, i personalty do this no developer task :
- Write and post release announcement with screenshots. It long and need
English words review.
- Update weekly bundles for Windows, Linux, and Mac. This require to
install compilation env. and to run/update/fix bash/cmake scripts that i
write.
Mostly all is now automatized with scripts and well documented.
- Bugs triaging : I already create/sort/manage all digiKam bugzilla
subsections, make a huge pass over all entry, identify the duplicates,
etc... But this need to be done periodically, and while this time you
cannot code.
- Write the doc : we have a huge documentation written in docbook format, a
kind of XML stuff not to hard to understand. This need large updates, with
new screenshots. I must admit that i don't touch the doc since a long time.
- Translate well the application and the documentation. It's not too hard,
but long. There are delegate teams for translations jobs into KDE project.
>
> 1.
>
> ...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.
>
> @Gilles:
> 1. is there any space where some idealist could find each other
> and try to do so under your supervision
>
> - digikam-devel at kde.org mailing list is a good start, but using a mailing
list is limited (size attachement, moderating, history, etc.).
- Linkedin digiKam group can be used well.
Do not ask me to use IRC. I cannot do it while working hors, as IRC is
closed due to security issue with FW. Linkedin message do the job well, and
students are in this social network. I know that it's not perfect, but at
least we can use it to work together. Remember that G+ social network will
be closed in 2 April and we cannot use it instead (thanks google for the
long time support).
>
> 1. could you tell where to there right spot in the source code for
> such enhancement?
>
> I already start to respond to this question in another post (this is the
problem of mailing list for ex)
Best
Gilles Caulier
>
> 1.
>
> here are the clarifying statement about the near future of digiKam
>
> No. Personalty, i must for 6.1.0
>
> 1/ Finalize the internal plugins API for Genric, Editor, and BQM.
> 2/ Document the API
> 3/ Export the API for external contribution. Currently all plugins are
> inside digiKam project.
> 4/ Prepare the rooms for the new students.
>
> Later 6.1.0 :
>
> 1/ Prepare new plugins interface as :
> ...
> * 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.
>
>
> Stefan
> Am 27.01.2019 um 22:47 schrieb Leo Gaspard:
>
> 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" <stefan.mueller.83 at gmail.com> <stefan.mueller.83 at gmail.com> writes:
>
>
> 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 <caulier.gilles at gmail.com> <caulier.gilles at gmail.com> writes:
>
> Le sam. 26 janv. 2019 à 02:13, Leo Gaspard <digikam-users at leo.gaspard.io> <digikam-users at leo.gaspard.io> 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 <digikam-users at leo.gaspard.io> <digikam-users at leo.gaspard.io> writes:
>
> Hello world!
>
> I have tried IRC to bother the fewest possible people, but it looks like
> #digikam at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20190202/a08920a8/attachment.html>
More information about the Digikam-users
mailing list