Ticket #74 (enhancement)

patch to allow displaying of embedded images in html attachments when using gtmmozembed

Thanks, I will review this and commit once okay. Probably this weekend.

Let me know if you need me to change something...

First thing I see in the patch that is a security fault is that you are not using tmpnam or even better, g_mkstemp, to determine the temporary file.

You are creating your own singly linked list whereas glib gives you something usable for this with either GList, GSList, GHashTable and GPtrArray already. You should refactor to use those list types unless you have a good reason to utilize your own linked list implementation.

Printing to stderr should never happen. Either it's a programmer's error in which case you use g_critical, or it's an error that should be handled by the app developer in which case you pass a GError **err variable and use the GError API of glib to set the error value.

To check the content type you MUST use the tny_mime_part_content_type_is, don't check manually with strncasecmp("image/", content_type, 6) because there are various things you are getting wrong this way.

With FILE *fp = fopen("/tmp/michele.html", "w"); you are writing to a file in /tmp for no reason whatsoever. I'm guessing this was for debugging? Please remove it.

Note that tny_moz_embed_stream_write happens in chunks for 1024 bytes. If your IMG tag is cut in the middle of such a chunk, then your replacing code wont work. You need to make sure that if an IMG tag got cut, that you cope with this situation.

Also note that it should be possible to make viewing the images optional by configuring the instance. For example a tny_gtk_moz_embed_msg_view_set_view_images (inst, FALSE).

The reason for this is that some devices use level wearing flash devices for storage of /tmp or even worse, a ramdisk consuming the device's physical RAM modules.

The application developer who's using Tinymail might want to disable your feature for that reason: excessive writing to /tmp or consuming a lot of RAM is not always the right strategy to handle viewing an HTML E-mail with images.

Also note that you should use the tny_mime_part_decode_to_stream_async API in stead of the tny_mime_part_decode_to_stream API. Else you make your code blocking at that location (if the part is not yet downloaded, it'll download and only return once it's fully downloaded. This is about large image data, so doing it nonblocking with the async version of the API is definitely required here).

Final note about the nonblocking async API: You can instruct the HTML component to start viewing the image in the callback of tny_mime_part_decode_to_stream_async (that callback is one of its parameters).

Once you do this, you also need to pass a status_callback and a status_user_data which you could let the application developer pass upon construction of the instance, for example (and store them for later, when the decode-call takes place).

For example the TnyGtkImageMimePartView? does this too, you can use the existing ones as example of course.

Have fun improving your patch.