<p>Hello, Nikolaj.<br></p><p>Just in case resending to <a href="mailto:amarok@kde.org">amarok@kde.org</a> and btw alongside I can develop support of Ampache and it's missing functionalities.</p><p>I'll make a proper application for the second proposal about xmms2 etc. soon.</p>
<p>---</p><p>Yeap, you did get it right. Those parts about Ampache that you wrote are also correct.<br><br>And yes, communication of other amaroks will be very complicated task. And it's realization includes something more than just Ampache. It can be a daemon along side with Ampache and it'll act through it's own protocol. And the goal is not to just share the content of amaroks between users, but in the same time to make download process from server a lot quicker using the content of the nearest amarok. Also users will be able to download some of the content from Ampache even if it's down. So the benefits are obvious and I'd be happy to contribute this functionality under GSOC ;)<br>
<br>Also I have another proposal about Amarok - nowadays everybody invents a bicycle using different GUI for services such as xmms. mpd etc. And a lot of my friends who uses stuff like that would like to have an ability for Amarok to communicate with such services (playing directly through it, geting playlists, album-pictures) through their API. The idea is to make an Amarok service a client-layer for those services.<br>
<br>I submited my proposal to KDE category, I hope to be able to do my best ,)<br>---<br></p><p><br></p><br><div><span class="gmail_quote">2008/3/25, Nikolaj Hald Nielsen <<a href="mailto:nhnfreespirit@gmail.com">nhnfreespirit@gmail.com</a>>:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Alex<br> <br> Thanks for your proposal.<br> <br> If I understand your proposal correctly, what you want to achieve is<br> basically to allow Amarok to fetch its content from a server, as well<br> as from other instances of Amarok. Is this correct?<br>
 <br> With regards to the server, we already have the Ampache server service<br> which can accomplish much of what you want to achieve. Also, there is<br> a proposal to add up and download functionality to the Ampache<br>
 service, so that will go some way to achieve what you wish.<br> <br> As for allowing different running Amaroks to share content, this goes<br> way beyond what the service framework is currently capable of and<br> would likely be a very large project in its own right. If this is<br>
 something you want to explore, you should write our mailing list at<br> <a href="mailto:Amarok@kde.org">Amarok@kde.org</a> so the other developers can also give their opinions.<br> <br> Also, please look at <a href="http://code.google.com/soc/2008/">http://code.google.com/soc/2008/</a> for some<br>
 information about writing and submitting proposals. Proposals for<br> Amarok goes in the KDE category.<br> <br> Feel free to mail me any question, but I will also see your mails if<br> you send them to <a href="mailto:amarok@kde.org">amarok@kde.org</a>, and as others will be able to answer<br>
 you there as well, the replies will likely be quicker! .-)<br> <br><br> - Nikolaj<br> <br><br> On Tue, Mar 25, 2008 at 11:31 AM, Alex Kosenkov <<a href="mailto:alex.kosenkov@gmail.com">alex.kosenkov@gmail.com</a>> wrote:<br>
 ><br> ><br> > Hello there, I want to introduce my ideas about Amarok: adding a new<br> > service.<br> ><br> >  This can be completely outstanding feature of Amarok amongst all other<br> > players.<br>
 ><br> > Basically, I don't like usual approach to store all audio data on local<br> > hard-drives, yeah it is kind of stable, but in this case a lot of space on a<br> > hard-drive is just wasted and very often work with hd becomes a bottleneck<br>
 > for hardware. But now we have an Internet. Especially when we have a local<br> > network - it's much more effective to store the whole data on a specific<br> > server, which will be manipulating all the data (basically it is the<br>
 > unix-like approach to do things - make each separate detail do it's own work<br> > and polish it). And MORE: we can make an ability for users to collaborate<br> > with each other even when the main server goes offline. And I can make these<br>
 > features as flexible as it's possible.<br> ><br> ><br> > See details in attachment.<br> ><br> > --<br> ><br> > Best regards, Alex Kosenkov<br> </blockquote></div><br>