id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
23471,"Abstraction of post format parameters (wp_update_post(), XML-RPC, template tags)",johnbillion,,"#19570 is introducing a UI for post formats. Correspondingly, various post meta fields will be introduced to store the extended data that's used in some post formats (eg. the URL field for a link or the source field for a quote).

Anything that interacts with the XML-RPC API and wants to support post formats (eg. future versions of the [http://wordpress.org/extend/mobile/ WordPress mobile apps]) will therefore need to:

 1. Send the various post format meta fields in its requests, and
 2. Receive the various post format meta fields in responses.

There should be some abstraction available at all levels of saving and fetching posts, don't we have to deal with the post meta fields directly. We should:

 1. Introduce a new parameter to the `wp.newPost` and `wp.editPost` XML-RPC methods for specifying the values of the extended post format fields when saving posts,
 2. Introduce a new parameter to the `wp.getPost` and `wp.getPosts` XML-RPC methods for returning the values of the extended post format fields when fetching posts,
 3. Introduce a new parameter to `wp_update_post()` for specifying the values of the extended post format fields when saving posts, and
 4. Introduce template tags for displaying/returning the values of the extended post format fields.

Point number 4 may be being covered somewhere else. I know it's been mentioned in IRC but I couldn't find mention of it on Trac.

The end result of this is that extended post format data is abstracted from its storage method.

Consideration: Which of these fields will be required and which are optional (on a per-post-format basis).

Thoughts? I'm happy to volunteer a first patch (or patches).",enhancement,new,normal,Future Release,General,trunk,normal,,,