Hi Sergio (and everyone else),
Jose sent me a couple of suggestions - he agreed that the code
looked correct, too - he thought that maybe I just needed to
reset the stream in my callback function (his first suggestion),
like so:
// remember to RESET the stream back to its start point!
tny_stream_reset (stream);
// for now, just see if we can read all the bytes in the decoded
stream - we'll
// display the contents later...
while ( !tny_stream_is_eos (stream) )
{
nb_read = tny_stream_read (stream, tmp_buf, sizeof (tmp_buf));
nb_total += nb_read;
}
g_print ("decode_to_stream_callback => number of bytes read from
the TnyStream = %d\n", nb_total);
And, that one small change made it work just fine - so now
I can
get to the main body of a message!
Thanks again to you and everyone else for helping me to get over a
few of these "getting started" humps - it's very much appreciated!
Also, after I finish off my little console application, I'll be more
than happy to contribute it to the repository (in the "tests" folder),
for the benefit of anyone else that might want to have a fully
functional
console application that uses the TinyMail library, but doesn't use
any of the current UI framework implementations.
- Steve Rosen
Sergio Villar Senin wrote:
En 19/05/10 22:20, Steve Rosen escribiu:
Hi Br (and everyone else),
Thank you - that was exactly the case - when I sent an email
to that Gmail account with an attachment, I suddenly saw
my iterator was valid and was then able to see both of the
mime parts (the "text/plain" and the "application/pdf").
So, I see this as a bug - the "tny_mime_part_get_parts()"
function SHOULD return a list for the degenerate case, where
you have an email that just has a single mime part - there
does not seem to be an API to query a message, asking for
the number of mime parts that it contains! This means you
have to call the function to get the mime parts, and if the
iterator that gets returned is "done", the assumption is
that there is only 1 mime part - pretty silly. Should I
file a bug? The function that is responsible is this one:
tny_camel_mime_part_get_parts_default
If you look at its logic, it clearly misses the case where
you have a single mime part TnyMsg ! I'd offer to fix it
myself, but I'm not familiar enough with the TinyMail CAMEL
implementation to confidently address this issue.
Pretty silly ? I don't see that as silly. We don't plan to add more API
for that case as it's enough with the current API.
So here is my code snippet that will workaround for the bug:
// time to get to the MEAT of this message - we start out by
// getting all the mime parts of this message...
TnyList * l_mime_parts = tny_simple_list_new ();
tny_mime_part_get_parts (TNY_MIME_PART (msg), l_mime_parts);
TnyIterator * iter = tny_list_create_iterator (l_mime_parts);
if( tny_iterator_is_done (iter) )
{
// we only have ONE mime part, so show its content type...
// (this is a bug in tny_camel_mime_part_get_parts_default!!)
g_print (" => mime_part content
type : %s\n",
tny_mime_part_get_content_type (TNY_MIME_PART(msg)) );
} else {
while (!tny_iterator_is_done (iter))
{
// okay - we have some mime part of this message - show its
type...
TnyMimePart * l_mime_part = TNY_MIME_PART
(tny_iterator_get_current (iter));
g_print (" => mime_part content
type : %s\n",
tny_mime_part_get_content_type
(TNY_MIME_PART(l_mime_part)) );
g_object_unref (l_mime_part);
// well, we're done with this mime part - onto the next
one...
tny_iterator_next (iter);
}
}
// we're done with the iterator and the message mime parts, so
cleanup...;
g_object_unref (iter);
g_object_unref (l_mime_parts);
Thanks again for your help on this issue.
This is not a workaround. Actually is exactly the way you should do it.
Now for the next question - once you have the mime part that you want
(in this case, the "text/plain" mime part), HOW do you then read the
body of the message? Just an outline will do...
Again, I don't want to use any TinyMail UI framework stuff - just the
low-level APIs to simply read the body of an email (where the mime-type
is just "text/plain").
Here is what I thought I should do (after seeing that I have a mime part
type of "text/plain", for example):
CamelStream *stream = camel_stream_mem_new ();
TnyStream *dest = TNY_STREAM (tny_camel_stream_new
(stream));
tny_stream_reset (dest);
tny_mime_part_decode_to_stream_async (TNY_MIME_PART(msg),
dest, decode_to_stream_callback, NULL, NULL);
g_object_unref (dest);
Then, my "decode_to_stream_callback" functions looks like this:
static void
decode_to_stream_callback (TnyMimePart *self, gboolean cancelled,
TnyStream *stream, GError *err, gpointer user_data)
{
// announce that we got called back to decode a stream for some
message mime part..
g_print ("decode_to_stream_callback => Time to decode a stream
for some text/plain mime part, cancelled = %d\n", cancelled);
char tmp_buf[4096];
gssize nb_total = 0;
gssize nb_read;
// for now, just see if we can read all the bytes in the decoded
stream - we'll
// display the contents later...
while ( !tny_stream_is_eos (stream) )
{
nb_read = tny_stream_read (stream, tmp_buf, sizeof (tmp_buf));
nb_total += nb_read;
}
g_print ("decode_to_stream_callback => number of bytes read from
the TnyStream = %d\n", nb_total);
return;
}
Unfortunately, this does not seem to be quite right, as I always show
that I
have read 0 bytes - so, any hints on this issue? Thanks again in
advance for
any help / assistance ...
Seems correct. I'll take a look later more in detail.
Br
|
