Comment 6 for bug 281476

> Surely the content mime-type of the file is available in the
> database too?

It's on the ILibraryFileAlias, which is also where the original
filename is stored, and so is similarly obscured by the
Bytes/HostedFile mechanism. However, unlike the filename, it's not
available on the HostedFileBuffer object returned from
HostedFile.open().

> When you GET an attachment URL in the web service you're redirected
> to a URL on the librarian. The last path element of the librarian
> URL is the file's current filename.
...
> Is this an interesting idea?

It is, but it seems hackish too. It would break the consistency of the
API for clients not using launchpadlib.

Using attachments in launchpadlib is something like:

  >>> attachment = bug.attachments[0]
  >>> attachment_data = attachment.data
  >>> attachment_fd = attachment_data.open()
  >>> attachment_content = attachment_fd.read()
  >>> attachment_filename = attachment_fd.filename

To me at first it would seem intuitive to provide attachment.filename
and attachment.mime_type, but those attributes could legitimately
appear on attachment_data or attachment_fd too. Which is a little
confusing.

Now, the attachment_data step above corresponds to ILibraryFileAlias
(though it's not a regular API export of ILibraryFileAlias), so thats
where filename and mime_type should really be exposed.

The expose-attachment-filename-bug-281476 branch (diff:
<https://pastebin.canonical.com/11277/>) exposes the filename at the
attachment step because it's a regular API export and so easy to do,
and is not necessarily the best thing to do.