Re: [Musicpd-dev-team] mpd patch | mpd discussion about stickers

2009-04-14 Thread Max Kellermann
On 2009/04/14 06:05, Sébastien Houzé sebastien.ho...@gmail.com wrote:
 I have some time to spare on mpd in coming weeks and have opened my
 first mantis issue with a little patch :
 
 http://musicpd.org/mantis/view.php?id=2255

I don't think the log file should be used for anything but error
analysis.  We simply cannot give any guarantees on the text format.

If you want to have statistics, run a client like mpdscribble.  We
could add statistics support to mpdscribble.

 NOW, ABOUT STICKERS
 
 Stickers is an interesting feature, but when you have many mpd instances
 sharing the same db sqlite doesn't fits well (too much concurrency).

Please provide benchmark results to back that thesis.  Right now, I
cannot imagine this is even measurable.

 So I have searched for an elegant solution to be free to choose any database
 system as a sticker storage backend.
 I've found very few libraries in C with database abstraction capabilities,
 except libgda :
 
 http://www.gnome-db.org/CodeExampleGdaSelect
 
 With libgda stickers can be stored in MySQL, sqlite or PgSQL to name a few.
 This implies, mainly :

How much faster will MPD be when using MySQL or PostgreSQL?

- Renaming in mpd.conf sticker_file into sticker_dsn (values can be e.g.
*sqlite:///somepath/somefile.db* or *mysql://user:p...@host:port/db*)
- Updating configure.ac : --enable-sqlite becomes --enable-sticker (or
--enable-gda ?)
- Refactoring sticker.c,h files to use libgda
 
 Please tell me what do you think about it.

We could make the sticker storage pluggable, so you can write a libgda
backend.  I'm quite happy with native sqlite support right now, and I
had initially considered using BerkeleyDB instead of sqlite.

When sticker storage is pluggable, we can extend that interface to
store the whole MPD music database.

Max

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team


Re: [Musicpd-dev-team] mpd patch | mpd discussion about stickers

2009-04-14 Thread Max Kellermann
On 2009/04/14 15:38, Sébastien Houzé sebastien.ho...@gmail.com wrote:
 Ok, but I run many mpd processes, this implies running many mpdscribble
 too... is a playlog_file option in mpd.conf better ?
 Think about some analogy with Apache accesslog and errorlog. Logging can be
 optionnal this way, and why not loggin format configurable (data, IP, song)
 like in Apache.

Hmm, I'm not comfortable with that idea, because this is a very
specific feature request which can be solved with a client.  Might be
more difficult for you because you're running multiple MPD instances,
but you can use the same init script for starting one mpdscribble per
MPD instance.

Any other opinions on the mailing list?

 I don't have benchmarked at the moment. Basically I was thinking that sqlite
 had poor performance (big file lock) if many mpd processes were running
 concurrent SELECT against it. It seems not, according to sqlite
 website.

sqlite is quite fast, in some use cases even faster than traditional
database servers.  Even if it's slower for us, I don't think it's too
important.  MPD isn't pushing a lot of pressure on the database.
sqlite is great because it doesn't require any special setup,
PostgreSQL or MySQL would be too much work for most MPD users.

 I even found some interesting feature :
 http://www.sqlite.org/sharedcache.html
 What do you think of using sqlite3_enable_shared_cache() in mpd ?
 This doesn't make multiple mpd processes perform better, but a single one
 yes.

No, not at all, because MPD doesn't open the sticker database more
than once at a time.

  We could make the sticker storage pluggable, so you can write a libgda
  backend.  I'm quite happy with native sqlite support right now, and I
  had initially considered using BerkeleyDB instead of sqlite.
 
  When sticker storage is pluggable,
 
 
 You think about storage plugins like, e.g. : flat file, sqlite, bdb, xml ?
 If so, I think some dsn syntax sould be used in mpd.conf.
 
 For example
 sticker_file /somepath/somesqlitedb.db
 should be instead
 sticker sqlite:///somepath/somesqlitedb.db

More like:

 sticker {
plugin gda
uri sqlite:///.
 }

Or:

 sticker {
plugin sqlite
file /var/lib/mpd/stickers.sqlite
 }

  we can extend that interface to
  store the whole MPD music database.
 
 
 You mean ID3 tag cache too ?

Yes.

Max

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team