XML-RPC support for audio module

I think this might work better as a separate module. We could put in into a contrib directory so that it's distributed with the audio module but it could be enabled separately. Thoughts?

this is probably a better title...

i think audio_get_node_list() should stay in the audio module, it looks pretty useful. the rest of it could sit pretty nicely in a contrib module.

personally, i don't like the current create/delete api functions. something like yours would probably be an improvement.

also, i noticed that you had a few calls to watchdog() in your patch. i'm guessing these are leftover from testing.

leoburd, are you interested in updating this now that a 4.7 version has been committed? i think it'd be pretty cool.

anyone want to pick this up?

I pulled out your unrelated fixes and committed them, thanks for those. I've reposted an updated version of your patch.

I like what you've done with audio_api_get_node_list() but for the time being, I think it should probably live in your audio_xmlrpc module. I'd rather not commit the audio module to a query API at this point. That way we can give some of the other audio based modules a chance to weigh in on what'd be useful for them.

I'm not really sure I like the re-addition of the audio_api_create_item() and audio_api_delete() functions. I know that you were updating your code from the 4.6 version but I think you should refactor it a bit:
* Push the code from audio_api_delete() into _audio_xmlrpc_delete_entry() which can call node_delete().
* Push the code from audio_api_create_item() into _audio_xmlrpc_create_entry() and have it call audio_api_insert() instead.
* It looks like in _audio_xmlrpc_value_from_node() you're being backwards compatible with the 4.6 version. The downside of this is that you'll be missing out on any additional metadata tags that the admin may enable. Perhaps you could try to adjust your structure to be more like that of the current audio module?

I'm not sure quite what to make of the message:

/* NOTE: In Drupal 4.7, there are many cases in which the value of $node->audio_file->filemime -- which is returned by file_save_upload() --
* is different from the value of $node->audio_fileinfo[mimetype] -- which is returned by mime_content_type().
* In Drupal 4.6, file_save_upload also used mime_content_type(). Unfortunately, the way Drupal 4.7 currently retrieves filemime
* tends to return a lot of mime types unknown/unknown. That's why I decided to use the old approach in the code below.
*/

Could I get you to open up a separate issue for that? It seems like if it is the case that we ought to be always use the MIME type returned by getID3...

On the whole this is looking very promising.

I use audio_api_insert() in my station archive module: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/station/archi...

Look at the _station_archive_add_file() function:

  // then create a new audio node with iT
  $node = audio_api_insert($file->filename, '%title', $audio_tags);
  $node->created = $timestamp;
  $node->audio_fileinfo['downloadable'] = 1;

  // find/create the proper taxonomic terms based on day and hour
  $node->taxonomy = _station_archive_get_taxonomy($timestamp);

  // only promote tracks with proper metadata
  $node->promote = ($program) ? 1 : 0;

  node_save($node);

The trick is to call it, then add any additional properties, and the call node_save again.

if you're going to work on this, i'd recommend that you build it against the audio module living in my sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/drewish/audio/

I pushed all the code into the attached module. I'm not sure it works at this point but I keep thinking I'll have some time to work on this.

Thank you for posting this code. I had planned to try to learn how to implement this myself. I am having some trouble trying to get the code to work though. I am planning to use a perl client and it complains that the return is not valid xml. Do you have any examples of client code that will work with this module?

Thanks in advance.

exigent99, i'm not very familiar with the module but i'd recommend that you try simulating input and capturing the xml output then opening it with firefox or some other program that will help you determine what's invalid.

one minor thing to check, be sure you're not using the devel module's page timer. that was messing up some xml output for me with another module.

drewish, thanks for suggestions although I am not sure of your meaning on the "page devel timer"? also what is "component code contrib"?

also I think I have figured out why my xmlrpc client in perl is complaining. I am using the Frontier::Client lib and it looks like it is stopping because drupal puts in a carriage return in the return document before the <?xml ?> tag. Haven't figured out how to stop it yet though.

Component: Code » contrib

was me updating the category on this issue.

if you don't know what the devel module is then you're not using it and don't have to worry.