Re: [mt-daapd-devel] xml-rpc
Status: Beta
Brought to you by:
andrew40
From: Ron P. <ro...@pe...> - 2005-03-02 02:55:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Sure, I have no problem with a daap based xml solution, whatever is > easy to implement is fine by me. As long as we're just adding options > to the daap protocol and not changing any existing ones, I guess we'll > be fine. I'm happy as long as I get my xml ansers from the server. If > we still manage to shoot ourselfs in our feet, it wouldn't be such a > biggie to change the code anyway. So, let's go with xml:ed daap. Wouldn't be the first time I've shot myself in the foot. But in this case, I think it actually make sense to do it that way. > As for getting things back to the server I don't care how the things > are formatted, it is probably easier for me to adopt to whatever is > easy to hack up in C. (Javascript actually is a pretty flexible > language, even if it's mostly looked upon as the visual basic of the > web.) > To begin with I only need to get a smart playlist definition back to > the server. I'm going to do a xml-or-dmap output format, then. Another thing that's going to change, assuming that we stick with a SQL backend (which I would *very* much like to do) is that playlists won't be kept in a file anymore -- they will be in the database, and instead of being a funky language, they will simply be a where clause. The "library", then, becomes a playlist, with a where clause of "1". But you could do cool stuff -- like have different libraries depending on what password was entered. Different users, essentially. Each user could have a base library playlist. Mine, for example, might be a playlist like "upper(genre) not like '%COUNTRY%'" So when I connect, what looks like the full library is really just a filtered version of the library. Then you could apply playlists to the "base" playlist by anding the playlist clause with the base playlist clause... select * from songs where (date_added > current_date - 7 days) AND (upper(genre) not like '%COUNTRY%') Query and browse falls out trivially, as well. So anyway -- gotta find a way to make a SQL backend... it sure will make stuff easy. Sorry. Got carried away. But yeah... I think that with both a xml and a dmap output, it will make it much easier. And the browse stuff, for the most part, could be re-written as an ad-hoc playlist. That would take three separate code paths and merge them into one. That would be nice. -- Ron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFCJSsODl/VbZJe82cRAvCwAJ46eLCvIn8Z0oDazchoO2HhDSKM3ACfaXOl b5F3k61TZPWkkJcBSYV0/24= =SY1j -----END PGP SIGNATURE----- |