Hi Nicolas,
On 19.11.04, Nicolas Évrard wrote: [snip]
The separation is fine. But we should only start the scrobbler service if it is used.
Indeed, this think is always triggered and that's not really the ideal behavior, I suppose there is plenty of people that don't want a site to know they are listening to the next unreleased big hit they just got via p2p.
Exactly.
But this all brings me to the point that it would actually be very nice, if we could make the audioscrobbler service the first PyTone plugin. These plugins then probably could handle their configuration files separately.
Would be a nice feature.
What do you think? It should not be too difficult to implement. Maybe, we have to make some iterations with the interface but in the end I think it would be useful for others as well. We could also provide a generic plugin class, which already does the setup of the threading stuff, etc.
Seems like a great idea.
We could have a directory in .pytonerc that stores all plugins. We prepend this directory to sys.path, query the conffile for the list of plugin to load. Then we call the start method of all the plugins (or anything else) and it's ok.
That's what I had in mind except for that we also need to have a global plugin directory.
I've got the felling this schema is good for plugins that gets informations, but if you want to provide pieces of information (retagging, ...) they will also need to send them. Maybe the hub should also be able to manage 'information providers' and 'information requesters'
You can already send information via the hub, for instance about changes in the song metadata. The only thing I want to do before we make this interface more publically availbale is to get rid of the ugly hub.hub.notify by adding a notify method to the hub module which uses the default hub. But these are minor issues.
Well, I'll try all these ideas tomorrow, please make comments about all this where you see fit.
Go ahead!
Jörg