API thoughts

[Ken Kennedy]

I've finally gotten enough time to start working on really using the API...some very good stuff, and some things that are still a bit of a challenge. *grin* I'm trying to both 1) wire rating a podcast at SpokenWord into my listening process, and 2) use SW for as much of the "datastore" as possible for my own podcatcher solution. If I threw out all previous work, data, etc., and jumped into #2 with both feet, that would allow me to do #1 without much difficulty; I'd have all the unique identifiers for a program, feed, etc. easily at hand.

But I see that as a bit of a brittle solution, since if nothing else, I'd like to be able to get my old data (previous listen/rating info from hand-rolled podcatcher) into SpokenWord. But right now, there's really no easy way to bridge the gap between data stored in another datastore (that doesn't have SW primary keys) and Spokenword. 

Search via the API appears basically broken; even with a unique title query (that returns only one program at the website: "site:spokenword.org/program In Sickness and In Power", for those interested), I get a hunk of non-relevant responses via the API that don't even include the correct program. Point being there that I have no way of tracking down a program to rate it (via it's SW program ID), without already knowing it's SW program ID. 

The other option I've hoped for would be a far simpler search on one or more of of the feed item GUIDs (realizing they're not always...well, globally unique) the enclosure url (again, not guaranteed to be unique), or the filename of the media file itself (same issue). NONE of these are guaranteed to be unique, but most of them usually are, and they are values that can be pretty easily indexed. 

If I have some way of identifying a program before I know it's SW program ID, then I can move forward with pushing my old data into Spokenword. I'm thinking of bootstrapping myself with several "big honkin' queries"'; I can stick my subscribed feeds into a spokenword collection, and then suck down the program information for those collections, which will include the SW program ID and guids and urls. I can use this to build my own index for now, and start pushing my ratings back into Spokenword as I listen. 

The ability to add objects (programs for me primarily) to a collection via the API would also be useful, as I can then use collections to keep track of things like "programs in the queue for listening", or "stuff I've watched on Miro", etc. Since I use several different programs/tools to consume the sort of media I would rate in Spokenword, it'll help to separate things out. 

Also, a "I have listened to this, but not yet rated" attribute would be useful. I will end up using another collection for it, and that works, but it's really an attribute of the program. That would allow things like the ability to bring up a feed in a "rating" mode, where you were only shown programs that you'd listened to but not rated, in the same UI as the current feed view, which I like. Again, I can do this with a collection; so this is a nice-to-have, not a showstopper (if there were a view option for a collection/playlist that was similar to the current feed view, it would also allow quick ratings. That would be nice.)

Those are some initial thoughts. I'm very much looking forward to continuing to work on integrating SW into my podcatching and rating workflow; I definitely think it will work! Thanks for all the hard work, Doug.

--
Ken Kennedy
Contact info: http://kenzoid.com/me/contact

[Doug Kaye]

Finally, some response to Ken's writeup below...

On Tue, Nov 24, 2009 at 7:16 AM, Ken Kennedy <kken...@kenzoid.com> wrote:

Search via the API appears basically broken.

That's correct. My goals for the search API were too ambitious. When it worked well (rarely) it was way too CPU-intensive. Two things will happen with search (1) there will be a scaled-back search that doesn't support such a broad spectrum of simultaneous parameters, and (2) I want to get the funding for a developer to work on a solr-based search, running on separate servers.

 

The other option I've hoped for would be a far simpler search on one or more of of the feed item GUIDs (realizing they're not always...well, globally unique) the enclosure url (again, not guaranteed to be unique), or the filename of the media file itself (same issue). NONE of these are guaranteed to be unique, but most of them usually are, and they are values that can be pretty easily indexed. 

I'm thinking of implementing search by media-file (enclosure) URL. It's the one item that *should* be unique for each program. GUID and filename aren't good enough.

The ability to add objects (programs for me primarily) to a collection via the API would also be useful, as I can then use collections to keep track of things like "programs in the queue for listening", or "stuff I've watched on Miro", etc. Since I use several different programs/tools to consume the sort of media I would rate in Spokenword, it'll help to separate things out. 

Yes, this should be coming soon. I wanted to hold off until I knew the overall API structure was sound, and we're just about there.
 

Also, a "I have listened to this, but not yet rated" attribute would be useful.

Not sure what you mean here. We don't keep track of what you've downloaded or streamed. Do you mean that we should allow you to set this attribute and save it for you? I don't think that makes sense. Why not store it yourself?

Thanks.

     ...doug

[Thilo Planz]

>
>> Also, a "I have listened to this, but not yet rated" attribute would be
>> useful.
>>
>
> Not sure what you mean here. We don't keep track of what you've downloaded
> or streamed.

My workaround for this is keeping an omnibus collection
that contains everything that I listen to (or rather: am likely
to listen to, i.e. subscribe to).
I can filter out what I have already ready rated from there.

Of course, that collection contains lots of stuff that
I did not yet listen to.

But it is much easier to find a programme that I want to rate
in there than trying to use the search functions.

Thilo

[Ken Kennedy]

On Sat, Dec 19, 2009 at 2:26 AM, Doug Kaye <do...@rds.com> wrote:

Finally, some response to Ken's writeup below...

The other option I've hoped for would be a far simpler search on one or more of of the feed item GUIDs (realizing they're not always...well, globally unique) the enclosure url (again, not guaranteed to be unique), or the filename of the media file itself (same issue). NONE of these are guaranteed to be unique, but most of them usually are, and they are values that can be pretty easily indexed. 

I'm thinking of implementing search by media-file (enclosure) URL. It's the one item that *should* be unique for each program. GUID and filename aren't good enough.

That sounds excellent.

 

The ability to add objects (programs for me primarily) to a collection via the API would also be useful, as I can then use collections to keep track of things like "programs in the queue for listening", or "stuff I've watched on Miro", etc. Since I use several different programs/tools to consume the sort of media I would rate in Spokenword, it'll help to separate things out. 

Yes, this should be coming soon. I wanted to hold off until I knew the overall API structure was sound, and we're just about there.

I saw that's now available! Looking forward to trying it out.
 

 

Also, a "I have listened to this, but not yet rated" attribute would be useful.

Not sure what you mean here. We don't keep track of what you've downloaded or streamed. Do you mean that we should allow you to set this attribute and save it for you? I don't think that makes sense. Why not store it yourself?

Because I actually was (and still am) considering trying to use SW as the full "backend" to the media management system for my podcast listening. There's so little extra data that I'd NEED to store anywhere else that I was hoping I could actually avoid using another datastore. Now that collection additions/subtractions are working via the API, I can solve that issue to a certain extent with collections...I can add an attribute to a program by putting it in a collection.

[Ken Kennedy]

On Sat, Dec 19, 2009 at 4:15 AM, Thilo Planz <thilo...@googlemail.com> wrote:

My workaround for this is keeping an omnibus collection
that contains everything that I listen to (or rather: am likely
to listen to, i.e. subscribe to).
I can filter out what I have already ready rated from there.

Of course, that collection contains lots of stuff that
I did not yet listen to.

But it is much easier to find a programme that I want to rate
in there than trying to use the search functions.

I've done a very similar thing, Thilo. And now that we can move things into and out of collections via the API, that should make that sort of thing a lot easier.