Attachment API Refactoring (RFC)

The current attachment API requires the client to explicitly check for the type of API used and then perform the actions by itself. This is sub-optimal for two reasons:

1. Adding one extra attachment type will break all the existing code;
2. It is cumbersome to use and leads to duplication.

• Expose a high-level API to users , relieving them from having to query any configuration options

• Any changes in functionality of the attachment API;
• Adding new attachment backend implementations

The API should hide all details from the user and offer convenience methods such as

bug_attachment_get_contents ( $t_attachment_id )

bug_attachment_download_contents ( $t_attachment_id )

bug_attachment_put( $t_attachment_data )