FeedAPI Integration
beeradb - July 9, 2008 - 04:14
| Project: | Youtube API |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | beeradb |
| Status: | closed |
Description
I've created a patch that gives a first go at feedapi integration.
| Attachment | Size |
|---|---|
| feedapi_integration.patch | 11.11 KB |
#1
Just a couple thoughts, I was pretty tired last night and didn't include them, so I thought I'd post a followup.
1). This needs to be moved into it's own module.
2). Currently this does not support feeds which require authentication. I need to talk to Aaron Novak and see if perhaps we can work out a way to add headers to the request being sent. Currently I don't see that it's supported by feedapi, so any support of it on my end will be in the future.
3). I'm thinking I might require emfield as well for this module, I'm not a fan of just putting the theme result in the body, as it offers very little flexibility for theming.
4). I'm thinking it's smart to keep the video object around somewhere, so it can be easily accessed without hitting YouTube again. Currently I'm thinking just a table with the video_id and the serialized video object, I need to think a bit more on whether that's really how I'd like to do it though.
#2
After talking with Aron briefly about feedapi it seems authentication can be handled in the parser, which is a lightbulb that failed to switch on for me on the first try. There's still a question as to how to best handle capturing credentials for authentication, but that's relatively minor.
#3
I definitely agree with #1, and #2 seems to be taken care of.
#s 3 + 4 here seem closely related, and requiring 3 would likely take care of (most of) 4, but I don't think that emfield would be necessary under every circumstance. Here's a question: why not require emfield if you want to make nodes out of the feed, but not if you want to use feedapi's lightweight feed option? Either way, I definitely think that allowing users to put the result into a node is key, since without it you'd lose views support, and as you mentioned it would make theming very difficult.
If you're going to go the emfield route, you'll also gain the use of the embedded video field feed_api mapper which makes it so that users can grab any sort of info that is attached to the xml that emfield grabs from YouTube and put it into cck fields.
#4
Alex,
First of all, thanks for the feedback.
3 + 4 do seem closely related. I've been thinking more on setting up caching of feeds/videos, and I think #4 can be delayed until that happens.
I'm thinking the best way to handle using emfield is to just detect if there is an emfield in the content type chosen, and use it if there is, otherwise I think just theming the video and sticking the output in the body of the node makes sense, although doesn't provide much flexibility for theming.
I already have a patch that takes care of the authentication, and expect to iron out the optional emfield stuff tonight.
New patch forthcoming!
#5
Updated patch. This patch provides authentication for feeds which need it.
In addition I've started auto-detecting node types for emfield video fields. In the event the node type has a video field, the module attempts to use that for the video storage. I'm having trouble making emfield fetch metadata for the video feed though, which results in it not displaying. Any tip on how to achieve that would be useful.
Left To-Do:
* Make emfield integration work.
* Move to own module.
* Improve comments. Also improve field description text in the feedapi settings form.
* Pretty sure I'll scratch any caching mechanism for now.
#6