[Bug 146865] New: networked, multiuser database backend

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug 146865] New: networked, multiuser database backend

Bugzilla from mikmach@wp.pl
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=146865         
           Summary: networked, multiuser database backend
           Product: digikam
           Version: unspecified
          Platform: Compiled Sources
        OS/Version: Linux
            Status: NEW
          Severity: wishlist
          Priority: NOR
         Component: Database
        AssignedTo: digikam-devel kde org
        ReportedBy: mikmach wp pl


Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

It would be great to have database stored on some sort of network disk with multiple users with access to it and possibility to share date about images, change status of image, metadata, etc.

This feature could make possible to use Digikam eg. in photo-agencies where multiple users have to had access to the same database. Even on personal level with photos from several members of family it would be good.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 146865] networked, multiuser database backend

Gilles Caulier-4
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=146865         




------- Additional Comments From caulier.gilles gmail com  2007-11-05 22:26 -------
Mik,

I would to start a reflexion about this B.K.O entry...

Mik, my vision is like your one : a computer host pictures + database. Remote computers  mount the file system shared over the network to play with images. Also Remote computers need to query remote database.

To share files, it's not a problem to use network file system (NFS-SAMBA for ex.) KDE4 version of digiKam _now_ support remote file systems (and multiple roots path).

For the Database, I see 2 solutions :

- using a deamon running on server and to query over the network. Dedicaced protocol will be used to query the deamon (XML based will be nice). This solution is undependant of the Database format/program (we can continue to use Sqlite3). This way do not require to change anything in SQL queries from digiKam DB interface

- using a database as MySql wich provide a deamon than it's possible to query using database protocol. This solution is dependant of the Database format/program and require a more unified database backend (for ex. based on QtSQl). This way require to touch/adapt/change few SQL queries from digiKam DB interface.

I'm not a Database specialist. So tip from guru are welcome to guide us on this subject. Thanks in advance...

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 146865] networked, multiuser database backend

Bugzilla from mikmach@wp.pl
In reply to this post by Bugzilla from mikmach@wp.pl
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=146865         




------- Additional Comments From mikmach wp pl  2007-11-13 08:50 -------
Of course (and   pity :( ) I am not database  guru but I'd like to see
other feature:

Break users into Administrators and Users. Admins have rw access to
database, Users only r-. It is possible to store in database some
predefined values and later users can fill metadata forms from drop-down
menus without adding new entries. Even without segregation of users it
could lead to faster filling of forms. One one computer you could make
it with form history (as seen eg in Konqueror) but how to propagate it
between remote computers?

I am afraid it would require changes in DB layout so probably it is too
late :(

ps. It is idea from FotoStation.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 146865] networked, multiuser database backend

Gilles Caulier-4
In reply to this post by Bugzilla from mikmach@wp.pl
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=146865         




------- Additional Comments From caulier.gilles gmail com  2007-11-13 08:59 -------
Break users into Administrators and Users. Admins have rw access to
database, Users only r-. It is possible to store in database some
predefined values and later users can fill metadata forms from drop-down
menus without adding new entries.

sure.

Even without segregation of users it
could lead to faster filling of forms. One one computer you could make
it with form history (as seen eg in Konqueror) but how to propagate it
between remote computers?

This is the concept of client/server with admin messages to post.

I am afraid it would require changes in DB layout so probably it is too
late :(

DB schema is not yet frozen (:=)))

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 146865] networked, multiuser database backend

Kjetil Kjernsmo-3
In reply to this post by Bugzilla from mikmach@wp.pl
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=146865         




------- Additional Comments From kk kjernsmo net  2007-11-14 23:41 -------
I threw in a few votes just so that I don't forget this issue. I've worked with a few things like this. In my previous job, I worked with the photo galleries of http://my.opera.com/ In my experience, the relational model is rather inflexible and not very well suited for extensible data models. It can be replaced by something that's more flexible, the RDF model. So, I'd like to advocate that at some point, and I would like to contribute time to do it too, I'm just not ready to do it yet...

Also, for even more finegrained control, have a look at http://www.policyawareweb.org/ where they have been prototyping stuff to make statements about who should be able to edit, who should be able to see a picture (in Norway, there is a legal requirement that identifiable persons must be able to approve  that their picture is published).
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 146865] networked, multiuser database backend

brianr
In reply to this post by Bugzilla from mikmach@wp.pl
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=146865         




------- Additional Comments From bcr wt net  2007-11-15 15:17 -------
I would agree on the benefits of using an RDF model in this case given the tight constraints of a traditional relational model. Unfortunately its not unlike using an OODBMS, not too many people are familiar with them and you sometimes get knee-jerk reactions.

I'd like to help with the RDF approach if/when it might get underway.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 146865] networked, multiuser database backend

Arnd Baecker
In reply to this post by Bugzilla from mikmach@wp.pl
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=146865         




------- Additional Comments From arnd.baecker web de  2007-11-15 17:26 -------
Does the "RDF model" correspond to "Resource Description Framework"
http://www.w3.org/TR/REC-rdf-syntax/
(Currently I have no idea what this would achieve for digikam,
and in particular how it is related to the original wish;
so before reading the RDF primer I want to be sure that this is the
right pointer ;-)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 146865] networked, multiuser database backend

Gilles Caulier-4
In reply to this post by Bugzilla from mikmach@wp.pl
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=146865         




------- Additional Comments From caulier.gilles gmail com  2007-11-15 17:59 -------
Arnd,

yes, RDF = Resource Description Framework. This one is already used with XMP metadata for ex.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[Bug 146865] networked, multiuser database backend

Marcel Wiesweg
In reply to this post by Bugzilla from mikmach@wp.pl
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=146865         




------- Additional Comments From marcel.wiesweg gmx de  2007-11-15 18:19 -------
Nepomuk is based on RDF.
You do not define tables, but always have a triple: "subject - predicate - object" (would be the linguistic approach), ex. "image xy - height - 1024". You can then freely define "ontologies", which is roughly a list of attributes (an image has width, height, rating, comment). This is my understanding, I am not an expert and might get things wrong.
In my personal opinion, this is without doubt the right choice for a framework like nepomuk which aims to integrate not only traditional metadata of a wealth of formats, but also in the future more context metadata ("which image was sent to me by this person by mail?") - at least I hope so.

For our purposes, there are several problems:
- the depth of integration. Digikam is not accessing a data storage, it is deeply based on it, and stores not only metadata information.
- specialization on images: we do not need the general approach. We can define what we want.
- ease of implementation: Basing everything on RDF would mean a lot of complexity to bring all information together.
- existing source code: It would require a significant rewrite.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Bug 146865] networked, multiuser database backend

Gerhard Kulzer-3
In reply to this post by Bugzilla from mikmach@wp.pl
Am Tuesday 13 November 2007 schrieb Mikolaj Machowski:

> Break users into Administrators and Users. Admins have rw access to
> database, Users only r-. It is possible to store in database some
> predefined values and later users can fill metadata forms from drop-down
> menus without adding new entries. Even without segregation of users it
> could lead to faster filling of forms. One one computer you could make
> it with form history (as seen eg in Konqueror) but how to propagate it
> between remote computers?
>
> I am afraid it would require changes in DB layout so probably it is too
> late :(
When using a database server like MySql or Postgresql the rw access rights can
be implemented without changing the data structures. With sqlite this is a
different story, because - as to knowledge - access rights are global
attributes of the database and cannot be finegrained on a table or even
column level.

Gerhard

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

signature.asc (196 bytes) Download Attachment