---------- Forwarded message ---------- From: Alexander Botero-Lowry <[EMAIL PROTECTED]> Date: Dec 22, 2006 5:28 AM Subject: XMMS2 as music playing service (forw) To: [EMAIL PROTECTED]
Hi, I've tried to send this to etoile-discuss (which I am subscribed to) twice, the second time with notificiation enabled in my mailman settings and I never got anything though it was accepted by mail.gna.org, so I decided to send it directly to you since you have been doing stuff with multimedia on Etoile (and just a massive amount of stuff in general)! Hope it's interesting to you.. ------- Forwarded Message From: Alexander Botero-Lowry <[EMAIL PROTECTED]> To: [email protected] Subject: XMMS2 as music playing service Date: Thu, 21 Dec 2006 17:13:10 -0800 Sender: [EMAIL PROTECTED] Hi guys, I've just joined the list, so Hi there! I'm an XMMS2 committer and a FreeBSD ports committer, so pardon the bias. I have been reading quite happily about Etoile especially the idea of services. The concept of having tools that do specific tasks that can be plugged together is close to any UNIX geeks heart (though the GNOME people clearly aren't aware of that), and has been something I've wanted in a GUI for a while. This attitude was why I began to use and develop on XMMS2. XMMS2 [1] was started by Peter Alm (the XMMS1 guy) and Tobias Rundstrom, originally as a library-based (in the sense of being a shared object) music player. It was later decided to take a client-server apporach instead. XMMS2 provides a daemon (xmms2d) which plays back music, stores a media library with all music and playlists. The actual media library is very powerful, implemented as something we call Collections [2]. Collections are very powerful allowing for selecting and limiting music in a variety of ways. I won't go into a lot of detail, but you can read more about it at the page referenced below. Collections seems to fit well with many of Etoile's plans for searchability. The design philosophy employed by XMMS2 is also in line with Etoile ideas. We intend to implement a minimal set of features in the daemon. We often jokingly refer to XMMS2 as a music playing microkernel. Features like lyric browsing, album art [3] and so forth are implemented as clients which connect to the daemon and provide their desired functionality. We have recently been discussing the concept of ``service clients'' which are clients that can register commands for other clients, to allow an inter-client communication method. In this way, a user can get a slim music listening experience that does just what they need and not much more, or they can get an amarok style music experience (assuming there is an appropriate client.) Communication with xmms2d is done over a undocumented binary protocol via the client library. The protocol is undocumented so that clients won't implement the protocol incorrectly and are required to communicate with xmms2d the same as any other clients. The protocol is all async and provides signals and broadcasts. The client library is written in C with bindings for a variety of languages (Python, ruby, C++, Perl, and Java for now, there are LISP bindings somewhere as well). All the bragging and praising aside: the design goals and ideals for XMMS2 are in many ways similar to that of Etoile, and I think that it would make a great music playing service for Etoile with just a bit of nudging (providing Objective C or Io bindings for one). I am already starting to work on a Etoile/GNUStep client in ruby (but my Ruby is pretty stale, I'm mainly a Python programmer but pyobjc doesn't work with GNUStep) but that would be mostly an Application and not really a service. On the other hand, much of the base functionality could be provided by writing very simple clients as Services when the time comes that Etoile is able to be more service oriented. Anyways, keep up the amazing work, I'm really excited to see what is to come, Alex [1] http://wiki.xmms2.xmms.se/ [2] http://wiki.xmms2.xmms.se/index.php/Collections_Concept [3] http://wiki.xmms2.xmms.se/index.php/Album_Covers (outdated) ------- End of Forwarded Message _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
