====== Attachment API Refactoring (RFC) ======

===== Motivation =====

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:

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


===== Scope =====

==== Goals ====

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

==== Non-goals ====

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

===== Implementation considerations =====

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 )''