Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Mime and compose future
26 views
Skip to first unread message
Joshua Cranmer 🐧
Oct 20, 2014, 12:25:08 PM10/20/14
to
Prelude: if you're an add-on author and use gloda's MsgHdrToMimeMessage,
please read this message.
Over the summit, as we discussed some elements of the current compose
work I'm doing, we appear to have come to a consensus that the current
progress attempt of trying to slowly bend the code to the desired future
state with incremental changes is not a successful path forward.
Instead, the better way forward is to prepare the code for a giant
complete reimplementation--or at least a complete reimplementation via
an add-on, so that iteration on the implementation can move forward more
rapidly than the current rapid release allows. Naturally, this requires
identifying the APIs that can be sanely reimplemented and those that can't.
For MIME parsing, there is a clear missing API: the ability to convert a
MIME message into a body and attachments. This API appears to be
approximated for JS users by gloda's MsgHdrToMimeMessage, but the actual
result of that API is heavily dependent on libmime's quirks (encrypted
blobs get really funky trees)--since it looks like most users are either
only trying to get the headers (for which MimeParser.jsm generally
provides a better API already) or trying to get attachment details or
body text, it seems that deprecating the API in favor of a new
body/attachments API is the best long-term approach. If you use
MsgHdrToMimeMessage and such an API would not satisfy your needs, please
tell me ASAP.
In message composition, the missing API is building a MIME message from
a part tree--we do this manually in a few places, and the import code
abuses nsIMsgSend to try to get this working. The final API has a lot of
magic I'd like to add (e.g., autoselecting the
Content-Transfer-Encoding, autoadding Date or Message-ID headers if they
are missing) that are not ready-to-implement in the current C++
nsMsgSendPart basis for this interface. The other main entry point into
the code I'm writing is nsIMsgSend; while this is a very insane
interface, I think it is possible to reimplement the interface as it
stands, and reimplementation quite frankly needs to precede interface
improvements here.
For TB 38, I feel reasonably confident that I can provide
implementations of these two interfaces using current C++ infrastructure
(or C++ infrastructure after landing my current patch queue). Using
these interfaces internally is a different matter--I might be able to
use the part builder interface within the current nsMsgSend interface,
but the interface I'm designing is asynchronous and the current
implementation of nsMsgSend assumes file writing is synchronous.
In short, here is the rough work plan, ordered by priority so you can
see what's going to get dropped if schedules slipped:
1. Land current compose patch queue (add structured headers support to
nsIMsgCompFields)
2. Fix undisclosed-recipients issues in UI
3. Fix performance in header parsing
4. Implement msgIMimePartBuilder based on nsMsgSendPart
5. Implement msgIMimeParser based on libmime
6. Make jsmime-backed implementation of nsIMsgSend and
msgIMimePartBuilder (as an addon)
7. Use the new interfaces in current code
8. Make jsmime-backed implementation of msgIMimeParser (as an addon)
Any help, particularly in replacing current misuses of interfaces, would
of course be most appreciated.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
please read this message.
Over the summit, as we discussed some elements of the current compose
work I'm doing, we appear to have come to a consensus that the current
progress attempt of trying to slowly bend the code to the desired future
state with incremental changes is not a successful path forward.
Instead, the better way forward is to prepare the code for a giant
complete reimplementation--or at least a complete reimplementation via
an add-on, so that iteration on the implementation can move forward more
rapidly than the current rapid release allows. Naturally, this requires
identifying the APIs that can be sanely reimplemented and those that can't.
For MIME parsing, there is a clear missing API: the ability to convert a
MIME message into a body and attachments. This API appears to be
approximated for JS users by gloda's MsgHdrToMimeMessage, but the actual
result of that API is heavily dependent on libmime's quirks (encrypted
blobs get really funky trees)--since it looks like most users are either
only trying to get the headers (for which MimeParser.jsm generally
provides a better API already) or trying to get attachment details or
body text, it seems that deprecating the API in favor of a new
body/attachments API is the best long-term approach. If you use
MsgHdrToMimeMessage and such an API would not satisfy your needs, please
tell me ASAP.
In message composition, the missing API is building a MIME message from
a part tree--we do this manually in a few places, and the import code
abuses nsIMsgSend to try to get this working. The final API has a lot of
magic I'd like to add (e.g., autoselecting the
Content-Transfer-Encoding, autoadding Date or Message-ID headers if they
are missing) that are not ready-to-implement in the current C++
nsMsgSendPart basis for this interface. The other main entry point into
the code I'm writing is nsIMsgSend; while this is a very insane
interface, I think it is possible to reimplement the interface as it
stands, and reimplementation quite frankly needs to precede interface
improvements here.
For TB 38, I feel reasonably confident that I can provide
implementations of these two interfaces using current C++ infrastructure
(or C++ infrastructure after landing my current patch queue). Using
these interfaces internally is a different matter--I might be able to
use the part builder interface within the current nsMsgSend interface,
but the interface I'm designing is asynchronous and the current
implementation of nsMsgSend assumes file writing is synchronous.
In short, here is the rough work plan, ordered by priority so you can
see what's going to get dropped if schedules slipped:
1. Land current compose patch queue (add structured headers support to
nsIMsgCompFields)
2. Fix undisclosed-recipients issues in UI
3. Fix performance in header parsing
4. Implement msgIMimePartBuilder based on nsMsgSendPart
5. Implement msgIMimeParser based on libmime
6. Make jsmime-backed implementation of nsIMsgSend and
msgIMimePartBuilder (as an addon)
7. Use the new interfaces in current code
8. Make jsmime-backed implementation of msgIMimeParser (as an addon)
Any help, particularly in replacing current misuses of interfaces, would
of course be most appreciated.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
ishikawa
Oct 21, 2014, 4:56:36 AM10/21/14
to
On 2014年10月21日 01:24, Joshua Cranmer 🐧 wrote:
...
I mean the man-power seems quite tied up already and if you can skip this
part 3,
you may be able to move on to other API changes.
Just a thought.
I have no idea of the workload of each step here.
But fixing a "performance" issue
is a nicety that can wait kind of improvement IMHO.
(Unless, the performance is very bad, but I don't think
TB as it runs on the desktop PC is THAT SLOW.)
Also, find a few improvement paths may be shared by others while
the interface changes explained here sound too hard to understand for
average programmers who don't have in-depth prior knowledge of the code base.
.
> 4. Implement msgIMimePartBuilder based on nsMsgSendPart
> 5. Implement msgIMimeParser based on libmime
> 6. Make jsmime-backed implementation of nsIMsgSend and msgIMimePartBuilder
> (as an addon)
> 7. Use the new interfaces in current code
> 8. Make jsmime-backed implementation of msgIMimeParser (as an addon)
>
> Any help, particularly in replacing current misuses of interfaces, would of
> course be most appreciated.
>
Maybe you can try to explain "replacing current misuses of interfaces".
Oh, maybe people in the know already understand the issues with this short
phrase.
TIA
...
> what's going to get dropped if schedules slipped:
> 1. Land current compose patch queue (add structured headers support to
> nsIMsgCompFields)
> 2. Fix undisclosed-recipients issues in UI
> 3. Fix performance in header parsing
Are you sure the performance is THAT BAD?
> 1. Land current compose patch queue (add structured headers support to
> nsIMsgCompFields)
> 2. Fix undisclosed-recipients issues in UI
> 3. Fix performance in header parsing
I mean the man-power seems quite tied up already and if you can skip this
part 3,
you may be able to move on to other API changes.
Just a thought.
I have no idea of the workload of each step here.
But fixing a "performance" issue
is a nicety that can wait kind of improvement IMHO.
(Unless, the performance is very bad, but I don't think
TB as it runs on the desktop PC is THAT SLOW.)
Also, find a few improvement paths may be shared by others while
the interface changes explained here sound too hard to understand for
average programmers who don't have in-depth prior knowledge of the code base.
.
> 4. Implement msgIMimePartBuilder based on nsMsgSendPart
> 5. Implement msgIMimeParser based on libmime
> 6. Make jsmime-backed implementation of nsIMsgSend and msgIMimePartBuilder
> (as an addon)
> 7. Use the new interfaces in current code
> 8. Make jsmime-backed implementation of msgIMimeParser (as an addon)
>
> Any help, particularly in replacing current misuses of interfaces, would of
> course be most appreciated.
>
Oh, maybe people in the know already understand the issues with this short
phrase.
TIA
Tanstaafl
Oct 21, 2014, 6:25:26 AM10/21/14
to dev-apps-t...@lists.mozilla.org
On 10/21/2014 4:56 AM, ishikawa <ishi...@yk.rim.or.jp> wrote:
> But fixing a "performance" issue
> is a nicety that can wait kind of improvement IMHO.
> (Unless, the performance is very bad, but I don't think
> TB as it runs on the desktop PC is THAT SLOW.)
Sorry to tell you but yes, it is bad. I am constantly hitting Tab too
> But fixing a "performance" issue
> is a nicety that can wait kind of improvement IMHO.
> (Unless, the performance is very bad, but I don't think
> TB as it runs on the desktop PC is THAT SLOW.)
quickly after a match and the selected entry doesn't get populated, or
it gets populated with a warped 'name', something like:
Nam >> <Na...@example.com>
ISHIKAWA,chiaki
Oct 21, 2014, 10:20:51 AM10/21/14
to dev-apps-t...@lists.mozilla.org
On 2014/10/21 19:25, Tanstaafl wrote:> On 10/21/2014 4:56 AM, ishikawa
But I think technically, it is in the code for autocompletion, and
not in the "Fix performance in header parsing"
which was mentioned in the roadmap.
Sorry that I was not specific enough about the issue.
I have no idea whether the people gathered for Thunderbird summit
( https://wiki.mozilla.org/Thunderbird:Summit_2014 )
thought there is manpower to attack this slowness of autocompletion code.
I think it is time that the scarce man-power allocation ought to be
discussed more widely.
We can hardly keep up with the changes in the underlying code as the
busted C-C tree showed these days.
<ishi...@yk.rim.or.jp> wrote:
>> But fixing a "performance" issue
>> is a nicety that can wait kind of improvement IMHO.
>> (Unless, the performance is very bad, but I don't think
>> TB as it runs on the desktop PC is THAT SLOW.)
>
>> But fixing a "performance" issue
>> is a nicety that can wait kind of improvement IMHO.
>> (Unless, the performance is very bad, but I don't think
>> TB as it runs on the desktop PC is THAT SLOW.)
>
> Sorry to tell you but yes, it is bad. I am constantly hitting Tab too
> quickly after a match and the selected entry doesn't get populated, or
> it gets populated with a warped 'name', something like:
>
> Nam >> <Na...@example.com>
Aha, that slowness is something I also want to see removed.
> quickly after a match and the selected entry doesn't get populated, or
> it gets populated with a warped 'name', something like:
>
> Nam >> <Na...@example.com>
But I think technically, it is in the code for autocompletion, and
not in the "Fix performance in header parsing"
which was mentioned in the roadmap.
Sorry that I was not specific enough about the issue.
I have no idea whether the people gathered for Thunderbird summit
( https://wiki.mozilla.org/Thunderbird:Summit_2014 )
thought there is manpower to attack this slowness of autocompletion code.
I think it is time that the scarce man-power allocation ought to be
discussed more widely.
We can hardly keep up with the changes in the underlying code as the
busted C-C tree showed these days.
0 new messages