Re: [Rhythmbox-devel] Rhythmbox Ampache (Source) plugin

[Seva Epsteyn <seva sevatech com>]

Jonathan,

Thanks for looking at it, I appreciate your suggestions.

> - Instead of storing usernames and passwords in gconf, it might be a
> good idea to store them in gnome-keyring

Of course, definitely on the to do list.  The Magnatune plugin I was using 
as sample has that code commented out, so I figured I'd better leave that 
for a later date.

> - Why is the source group configurable? The ampache source should just
> go in the 'shared' group

Primarily because I didn't know about the "shared" group and couldn't 
decide if I should create a new group for Ampache instances or stick it in 
the "library"

> - Having the source icon configurable is a bit weird too..

Yeah, the "hidden" options weren't really meant for gconf, I just didn't 
think of a better place to stick them at the time.

> - Does ampache publish its location using mdns or anything like that?
> If so, it'd be good to automatically find local ampache servers

I think I saw that feature requested (as part of DAAP), but I don't think 
that's the case right now.  My understanding is that mDNS is meant for LAN 
environment, while Ampache is just as suitable (and probably more commonly 
used) for access over Internet.

> in AmpacheBrowser:
> 
>         def do_set_property(self, property, value):
>                 # No idea what this is
>                 if property.name == 'plugin':
>                         self.__plugin = value
>                 else:
>                         raise AttributeError, 'unknown property %s' %
> property.name
> 
> you don't need this unless your source object is going to locate files
> in the plugin install directory
> (self.__plugin.find_file("something")).

Thank you for explaining that ;)  I just noticed the exception that would 
occur if this method wasn't around and swiped it from one of the other 
source plugins (probably Magnatune) verbatim.

>                 auth_xml =
> urllib2.urlopen("%s?action=handshake&user=%s&auth=%s&timestamp=%s" %
> (url, username, md5.md5(str(timestamp) + password).hexdigest(),
> timestamp)).read()
> 
> If you use rb.Loader class to do this (and to fetch the song list),
> the network activity will usually be asynchronous, so it won't block
> the whole UI. Some restructuring would be required, as the loader
> class operates using callbacks.
> 
>                 for node in dom.getElementsByTagName("song"):
>                         .. stuff ..
> 
>                 self.db.commit()
> 
> If you do a self.db.commit() every 1000 songs or so, the songs will
> appear in stages, rather than all at once; this tends to make it look
> a bit more responsive.


Yeah, I am definitely planning on having async I/O here to not block the 
GUI.  The load_db method was a test program I wrote to try Ampache XML API 
and when it worked I just dumped it in the load_db and posted to 
the Ampache forum and RB mailing list (as well as IRC channels) right away 
to get early feedback.

I am planning on working with quickplay.py (simple local GUI frontend for 
Ampache and mplayer) author to create a generic AmpacheCommunicator class 
so that stuff will also get abstracted away.

If anyone is interested I could create an account on my Ampache instance 
for testing.

-Seva