Client capabilities and intercommunication

This topic has been discussed intermittently - from different aspects - on IRC, with no real resolution. This page is here to aggregate the related points so we can make some progress on the topic. Feel free to add to this page..

Client communication

The XMMS2 IPC model is primarily client-server, however there are scenarios where it might be useful to have a more peer-to-peer approach, where clients talk to each other so that:

1. clients themselves stay small and only perform simple tasks (Make each program do one thing well. 1)
2. there is little duplication of functionality as a client of a certain type may provide certain service(s) to other clients.

Capabilities

We can perhaps identify specific capabilities or services provided by clients, so that:

• in a peer-to-peer model, some clients (in the sense of xmms2d client) can advertise and/or look for peer clients offering certain capabilities.
  • for example, cover-art viewer, playlist randomiser, etc
• in the client-server model, the daemon could simply keep a register of what clients have been started and what service(s) they provide (what their capabilities are), so that new clients starting up can know whether to enable or disable certain functionality. (e.g. to avoid conflicts)
  • a probable problem in this model is how to coordinate the process so that the user doesn't end up with clients that virtually 'deadlock' on enabling/disabling certain features.

Comments

I think this should made as simple as possible.

We already have client configvalue, so we can configure other clients, that solves most problems. Also executing other commands solves a good deal of problems. In my_simle_client I might have a "view coverart" button and a "manage medialib" button. When user clicks those my_simple_client simply execute "xmms2-coverart-viewer" or "xmms2-medialib-manager". (update-alternatives rocks!).

Do we need to solve any other problems?

--Anders Gustafsson 08:34, 13 Jan 2006 (CET)

I agree with Anders. I really doubt client devs want to bother sharing internal components of their client using P2P mechanisms. Sounds much more complicated than what anyone would ever want to do. Let's keep it simple and use programs as modules instead.

--Theefer 01:22, 14 Jan 2006 (CET)

I think it would be a good idea if clients that do background type functions (randomizer, audioscrobbler, osd) registered an "enabled" config value. So that one could simply disable a client when it is being redundent or not needed. For example usually I want my music random, but sometimes I want to listen to a whole album, so I'd like to be able to disable the randomizer without having to kill it and then restart it when I'm done.

--Alesbl 01:46, 21 Jan 2006 (CET)

This problem really calls for some standards. I'm in agreement that config properties seem to be the simplest way of doing things, but there needs to be a list of standard config properties and standard ways of communicating using those properties. We'll end up with client developers writing handfuls of clients for their big, pretty GUI client that don't interoperate with other developers' clients. A repository on the wiki for standardized helper client config values (and their authors!) is probably a good place.

I don't agree, however, that clients should spawn other helper clients themselves. There's a huge amount of complexity involved with locating the appropriate executable in a portable way, guaranteeing that the executable even exists, and guaranteeing that several clients don't simultaneously try to start the same program. Helper clients should be daemons as frequently as possible, and act only on appropriate config value changes. This eliminates all said problems with spawning helper clients.

--Puzzles 18:05, 09 Jan 2007 (EST)