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

[Tom Albers]

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

gr.

Toma
-------------- next part --------------
A non-text attachment was scrubbed...
Name: addContent2.diff
Type: text/x-diff
Size: 3359 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070227/9d5407d4/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: addContent2.simple.diff
Type: text/x-diff
Size: 664 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070227/9d5407d4/attachment-0001.diff>
-------------- 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/