[Kde-pim] mulitpart/alternative & mixed libkmime question.

[Volker Krause]

On Tuesday 27 February 2007 19:57:39 Tom Albers wrote:
> Op vr 16 feb 2007 11:17 schreef u:
> > On Thursday, February 15, 2007 11:57:33 PM Ingo Klöcker wrote:
> > > On Thursday 15 February 2007 23:31, Tom Albers wrote:
> > > > Hi,
> > > >
> > > > I'm trying to *compose* a message with three parts, one plain, one
> > > > html and one attachment. The plain and html are alternatives to each
> > > > other and the attachment should be visible for either version...
> > > >
> > > > Scenario 1:
> > > > Create Content A, fill it with plain content
> > > > Create Content B, fill it with html content
> > > > Add Content B to A. A will get converted to Mixed, with proper A and
> > > > B multiparts. Change the Mixed to Alternative.
> > > > Create Content C, fill it with attachment.
> > > > Add C to A. libkmime sees it's already a multipart and adds C as
> > > > third part to the message. Problem: C is not an alternative to A or
> > > > B. A & B should be in a seperate multipart part and that should be
> > > > together with C a mixed multipart.
> > > >
> > > > Scenario 2:
> > > > Create Content A. Dont fill it.
> > > > Create Content B. Fill it with plain.
> > > > Create Content C. Fill it with html.
> > > > Add Content C to B. B is converted to Mixed, with proper A and B
> > > > multiparts. Change the Mixed to Alternative.
> > > > Add Content B to A. A is converted to Mixed, there will be an extra
> > > > invalid/invalid part in the message. Create Content C, fill it with
> > > > attachment,
> > > > Add C to A, A proper part is added.
> > > > Problem: There is an invalid/invalid part added to the message. The
> > > > rest of the message is ok. If i grep that part and delete it from the
> > > > message, i loose the whole Alternative part. But that is a separate
> > > > bug.
> > > >
> > > > Is anyone able to tell me if either scenario is the right one?
> > >
> > > Both scenarios are awkward and obviously broken. IMO the right way
> > > (which KMime doesn't seem to provide or else you'd use it) is:
> > > Create Content A, fill it with plain content
> > > Create Content B, fill it with html content
> > > Create BodyPart::MultiPart::Alternative and add A and B
> > > Create Content C, fill it with the attachment
> > > Create BodyPart::MultiPart::Mixed and add the multipart/alternative and
> > > C.
> > >
> > > Apparently, the complete subtree starting with BodyPart described in
> > > CLASSTREE.bodyparts seems to be missing from KMime. :-(
> >
> > Indeed, nothing of this is actually implemented.
> >
> > From a quick look at the code, a small change to Content::addContent()
> > should help: If it is of type mulitpart even without having sub-contents
> > currently, it should not convert itself into a sub-content and create a
> > new multipart node, but just skip to appending the sub-content.
> >
> > That should make it possible to get close to Ingo's scenario if you
> > replace BodyPart::Mulitpart::... with Content and set its type
> > accordingly.
>
> Thanks for the hint, attached is a patch which does that. I included a
> 'simple' patch which is the same except for the extra indent, which makes
> the patch so much more readable in this case.
>
> With this patch, i'm able to do what i want, simplified:
>
> ------------------
>     m_main = new Message();
>     m_main->contentType()->setMimeType("multipart/mixed");
>     m_main->contentType()->setBoundary(KMime::multiPartBoundary());
>
>     Content* c_plain = new Content();
>     c_plain->contentType()->from7BitString( "text/plain" );
>     c_plain->fromUnicodeString( theText );
>     c_plain->assemble();
>
>     Content* c_html = new Content();
>     c_html->contentType()->from7BitString( "text/html" );
>     c_html->fromUnicodeString( convertToHtml( theText )));
>     c_html->assemble();
>
>     Content* c_maincontent = new Content();
>     c_maincontent->contentType()->setMimeType("multipart/alternative");
>     c_maincontent->contentType()->setBoundary(KMime::multiPartBoundary());
>     c_maincontent->addContent(c_plain);
>     c_maincontent->addContent(c_html);
>     c_maincontent->assemble();
>
>     m_main->addContent(c_maincontent);
>
>     Content* c = new Content();
>     c->setBody(KCodecs::base64Encode(data, true)); 	// attachment
>     m_main->addContent(c);
> ------------------
>
> I've grepped kdepim for addContent() and I could only find single entries
> in the knode code base, so that should not be effected. I did not see any
> entries in kmail. I think the maintainers of these apps should give there
> ok to the patch, and someone who understands libkmime a bit better then me
> ;-)

I've committed this patch to libkmime in trunk and added unit tests for your 
and KNode's usecase.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070302/cad303c7/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/