1

I like the direction Akonadi is taking with PIM (Personal Information Management) and creating a usefull backend architecture other PIM related software can rely on.
This coupled with Amarok's successful project in audio information management, I think a Project needs to be enjoined by each of the KDE media projects (Amarok, Kaffeine, etc) to define and implement a backend architecture similar to Akonadi (in idea, not necessarily code).
A MIM (Media Information Management) backend to provide the service of a database and change events to manage and compile the metadata associated with one's media (like the usuall tags, ratings, URL, playcount, etc...). This will service and maintain all the associated data a user (or multiple users =) wants to store. This backend will not be a playback service. The frontend applications, like Amarok for audio, and Kaffeine for video, would be responsible for their preferred media types (and depending on the users choice of playback engine, etc).
A MIM would further allow a separation via network, where one could have the metadata store on a server and multiple clients could interact with it.

Nepomuk can handle this. Several projects, including Amarok, have stated that they would be willing to move to nepomuk once it is fast enough.

@TheBlackCat: Thanks for the redirect.
I had seen Nepomuk quite awhile ago and saw it only as a specification with no real implementation and very high order of complexity (trying to cover the whole semantic cloud, as it were). If they can get a usable KDE framework (Soprano and Strigi I have seen) I hope the media projects will jump on it, as this will push huge amount of users to KDE (and devs too) [my video library needs it most]. I cant say I like the RDF / XML database from a performance POV, but things like CouchDB come along where RDBMS fail so things could improve radically.

However, Nepomuk covers only the metadata (AFA I have seen) and the KDE implementation covers only the local system. Will this allow for what I further described as a service on a separate host. Where in example, Akonadi, provides a encapsulated protocol based architecture, which could be situated anywhere (and with right plugins, eg. take over for exchange servers).

The basic premise is I want my media library (mostly audio and video, not necessarily photos, but I guess Nepomuk would make that option inclusive) to be accessible from any frontend that understands the backend protocol to be able to alter metadata and gain the info needed to stream it from said library.

Please revert this to a voteable brainstorm if Nepomuk is not the full solution to the idea, Thank you and Cheers.

First, Nepomuk does not only include metadata. It is a semantic system, catologing not only information but the relationship between information.. Second, Nepomuk already has a real implementation in KDE 4.3, and will be playing a much bigger role in 4.4. It is not only a specification.

Akonadi is a PIM management system. It is not designed for multimedia handling and I see nothing that it would provide that would make it suitable for this task. In fact, akonadi uses nepomuk, and further akonadi uses nepomuk precisely for the tasks that you are suggesting akonadi be used for. Adding an akonadi layer in between would not offer any real benefit.

The sort of network-independent media handling is done by existing backends like UPNP, which already has support being integrated into the KIO system. If you want network-independent multimedia handling, kio and nepomuk are the proper solutions, not akonadi. This is simply not what akonadi is designed to do. It is a PIM storage system, it is not meant for handling media. And from everything I have heard, it would not do a very good job at this task.

Ok. I hope I haven't been leading you down the wrong path. What I am trying to suggest, is to take advantage of the knowledge and know how put into the KDE technology, and Akonadi being a good example in similitude to the tech needed to give the understanding of the MIM I am describing, not using Akonadi as the actual service.

In other words, I am trying to suggest an amalgamation between an AV MediaServer and a similar structure in design to what Akonadi like projects do. UPnP is a protocol, but there needs to be a service (deamon) on the other end. Note: http://en.wikipedia.org/wiki/UPnP_AV_MediaServers. UPnP might well be the protocol of choice for media services to use. I was trying to give more of an overview, then tying the idea to any particular protocol.

So if I need to refactor the idea or this MIM:
- Use Nepomuk (or similar) implementation to store the metadata (and any other semantic data relating to the media files)
- Provide a protocol to interact with the metadata and the media files it refers to.
- The media files are stored be reference on the local or remote host's FS, thus utilizing a NFS like protocol instead of a DBMS for streaming.
- Put this together in a service (daemon) oriented way, so a client can use it locally or across a network as a backend service for metadata and streaming to the client the media file(s) needed.
- Thus a client app can use both a local media library and a remote library service (this is the big fish).

Again I referenced akonadi in example as their diagram on http://pim.kde.org/akonadi/ is fairly straight forward and only need to change the client app names.

Most AV media servers use a RDBMS to store the metadata and a local URL to the actual media file, the just handle SQL request for the metadata and a streaming protocal for the actual file transfer to the client.

I thought a more robust and socially / network scalable idea was presented in all the pieces coming together in KDE so it seemed to me a natural extention for this idea, and Akonadi triggered my thought along this direction.

If I am way off base, please let me know. I saw an avenue, like KMail was taking with separating the content storage into Akonadi, with apps like Amarok and Kaffeine to separate the content and metadata storage and just become good at presentation and playback of the media.

So I will have to look deeper into Amarok, if i have the time, to see if this is the direction they are taking (and they are not just focused on the local system as they have been with 1.4 and 2.x to date).

I would prefer further comments from others, so that is why I asked for the change in Status, so it can be voted on.

=) Cheers

I won't change the status, because as written the idea cannot and will not be implemented. If you talk about it more generally, the general idea is already in progress by combining upnp, kio, and nepomuk. upnp provides the protocol, kio provides the kde-based interface to that protocol in a network transparent manner (that is what kio does), and nepomuk handles indexing and metadata.

Neither situation is a valid idea. If you wish to have a discussion about networked multimedia you should open a thread in discussions and opinions. The brainstorm forum is not the place to have that sort of discussion. It is a place for specific ideas that can be submitted to and implemented by KDE developers as-written.