TB consistent message header from URI - Mozilla

This is a discussion on TB consistent message header from URI - Mozilla ; What would get me from a message URI/URL to the message header object regardless of source of the message? The message may be currently displayed in a window or in a paned arrangement, etc. The message may be loaded via ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: TB consistent message header from URI

  1. TB consistent message header from URI

    What would get me from a message URI/URL to the message header object
    regardless of source of the message? The message may be currently
    displayed in a window or in a paned arrangement, etc. The message may
    be loaded via the various protocols, local, or a file.
    messageServiceFromURI(url).messageURIToMsgHdr(url) did not work
    because messageServiceFromURI(url) failed for emails loaded from a
    file. I was using GetMsgHdrFromUri which magically worked even though
    the definitions I can find just use messageServiceFromURI
    (url).messageURIToMsgHdr(url). However GetMsgHdrFromUri does not exist
    for some of my testers so I may be getting that from an addon. I
    cannot seem to get a nsIMsgMessageUrl to use for
    nsIMsgMessageUrl.messageHeader. It is unclear to me how to get to a
    nsIMsgDatabase for all messages and then get a message ID or key for
    getMsgHdrForMessageID or GetMsgHdrForKey respectively.

    Thank you for any help you can give,
    Aron

  2. Re: TB consistent message header from URI

    On Feb 26, 11:06*am, gNeandr wrote:
    > *[26.02.2009 16:20] * *»Aron Rubin« wrote:
    >
    > > What would get me from a message URI/URL to the message header object
    > > regardless of source of the message? The message may be currently
    > > displayed in a window or in a paned arrangement, etc. The message may
    > > be loaded via the various protocols, local, or a file.
    > > messageServiceFromURI(url).messageURIToMsgHdr(url) did not work
    > > because messageServiceFromURI(url) failed for emails loaded from a
    > > file. I was using GetMsgHdrFromUri which magically worked even though
    > > the definitions I can find just use messageServiceFromURI
    > > (url).messageURIToMsgHdr(url). However GetMsgHdrFromUri does not exist
    > > for some of my testers so I may be getting that from an addon. I
    > > cannot seem to get a nsIMsgMessageUrl to use for
    > > nsIMsgMessageUrl.messageHeader. It is unclear to me how to get to a
    > > nsIMsgDatabase for all messages and then get a message ID or key for
    > > getMsgHdrForMessageID or GetMsgHdrForKey respectively.

    >
    > > Thank you for any help you can give,
    > > Aron

    >
    > Also it's not that clear what/how you want to achieve things around
    > messageheader and/or messageID, have a look at the following extension:
    > messageidfinder-2.0.0.xpi *http://messageidfinder.mozdev.org/index.html


    I saw that one before and I have a hard time believing that it is
    necessary. Someone must know a solid way to get to the message header
    from the URL. Then from the header you get the message id. In my case
    I am using the header to extract the list of all email addresses in a
    single message so I can create a map between phrase (name) and
    address.

    Aron

  3. Re: TB consistent message header from URI

    On Feb 26, 7:07*pm, gNeandr wrote:
    > *[26.02.2009 18:54] * *»Aron Rubin« wrote:
    >
    > > On Feb 26, 11:06 am, gNeandr wrote:

    >
    > >> *[26.02.2009 16:20] * *»Aron Rubin« wrote:

    >
    > >>> What would get me from a message URI/URL to the message header object
    > >>> regardless of source of the message? The message may be currently
    > >>> displayed in a window or in a paned arrangement, etc. The message may
    > >>> be loaded via the various protocols, local, or a file.
    > >>> messageServiceFromURI(url).messageURIToMsgHdr(url) did not work
    > >>> because messageServiceFromURI(url) failed for emails loaded from a
    > >>> file. I was using GetMsgHdrFromUri which magically worked even though
    > >>> the definitions I can find just use messageServiceFromURI
    > >>> (url).messageURIToMsgHdr(url). However GetMsgHdrFromUri does not exist
    > >>> for some of my testers so I may be getting that from an addon. I
    > >>> cannot seem to get a nsIMsgMessageUrl to use for
    > >>> nsIMsgMessageUrl.messageHeader. It is unclear to me how to get to a
    > >>> nsIMsgDatabase for all messages and then get a message ID or key for
    > >>> getMsgHdrForMessageID or GetMsgHdrForKey respectively.

    >
    > >>> Thank you for any help you can give,
    > >>> Aron

    >
    > >> Also it's not that clear what/how you want to achieve things around
    > >> messageheader and/or messageID, have a look at the following extension:
    > >> messageidfinder-2.0.0.xpi *http://messageidfinder.mozdev.org/index.html

    >
    > > I saw that one before and I have a hard time believing that it is
    > > necessary. Someone must know a solid way to get to the message header
    > > from the URL. Then from the header you get the message id. In my case
    > > I am using the header to extract the list of all email addresses in a
    > > single message so I can create a map between phrase (name) and
    > > address.

    >
    > > Aron

    >
    > Why not using:
    > * * * * var msgHdr = gDBView.hdrForFirstSelectedMessage;
    >
    > * * * * // subject
    > * * * * var summary = msgHdr.mime2DecodedSubject;
    > * * * * // from
    > * * * * var from = *msgHdr.mime2DecodedAuthor; * * *
    > * * * * // recipients
    > * * * * var to = msgHdr.mime2DecodedRecipients; * * *


    It is unclear to me whether gDBView.hdrForFirstSelectedMessage would
    work consistently for a message loaded from a file into a separate
    window. I have the rest of the code by the way, getting to the message
    header object is all I need.

    Aron

  4. Re: TB consistent message header from URI

    On Feb 27, 7:29*am, Neil wrote:
    > Aron Rubin wrote:
    > >What would get me from a message URI/URL to the message header object regardless of source of the message? The message may be currently displayed in a window or in a paned arrangement, etc. The message may be loaded via the various protocols, local, or a file.

    >
    > Files don't have a message header object. In order to satisfy some of
    > the internal commands, the UI creates a temporary object, but it doesn't
    > have any real properties set on it.
    >
    > --
    > Warning: May contain traces of nuts.


    That is extremely useful info thank you. Do you happen to know where I
    can collect the addresses then?

    Aron

  5. Re: TB consistent message header from URI

    On Feb 27, 11:34*am, gNeandr wrote:
    > *[27.02.2009 16:40] * *»Aron Rubin« wrote:
    >
    > > On Feb 27, 7:29 am, Neil wrote:

    >
    > >> Aron Rubin wrote:

    >
    > >>> What would get me from a message URI/URL to the message header objectregardless of source of the message? The message may be currently displayed in a window or in a paned arrangement, etc. The message may be loaded viathe various protocols, local, or a file.

    >
    > >> Files don't have a message header object. In order to satisfy some of
    > >> the internal commands, the UI creates a temporary object, but it doesn't
    > >> have any real properties set on it.

    >
    > >> --
    > >> Warning: May contain traces of nuts.

    >
    > > That is extremely useful info thank you. Do you happen to know where I
    > > can collect the addresses then?

    >
    > > Aron

    >
    > Falling back to the question: *where is/are the message/s stored to you
    > are going to work with? Are they stored to
    > -- a/some "plain" file/s outside of TB/mail system or
    > -- are they still part of the TB/mail system 'folder' file?
    > As posted also by Neil, that's a big difference how you can access the
    > info you need.


    I need to handle all cases. However to be more specific the problem
    was noticed when I load emails from plain text/".eml" files on the
    local filesystem. That is the case I am trying to solve presently as
    the IMAP and POP cases have been operating without issue.

    Aron

  6. Re: TB consistent message header from URI

    On Feb 27, 7:34*pm, gNeandr wrote:
    > *[28.02.2009 01:30] * *»Aron Rubin« wrote:
    >
    > > On Feb 27, 11:34 am, gNeandr wrote:

    >
    > >> *[27.02.2009 16:40] * *»Aron Rubin« wrote:

    >
    > >>> On Feb 27, 7:29 am, Neil wrote:

    >
    > >>>> Aron Rubin wrote:

    >
    > >>>>> What would get me from a message URI/URL to the message header object regardless of source of the message? The message may be currently displayed in a window or in a paned arrangement, etc. The message may be loaded via the various protocols, local, or a file.

    >
    > >>>> Files don't have a message header object. In order to satisfy some of
    > >>>> the internal commands, the UI creates a temporary object, but it doesn't
    > >>>> have any real properties set on it.

    >
    > >>>> --
    > >>>> Warning: May contain traces of nuts.

    >
    > >>> That is extremely useful info thank you. Do you happen to know where I
    > >>> can collect the addresses then?

    >
    > >>> Aron

    >
    > >> Falling back to the question: *where is/are the message/s stored to you
    > >> are going to work with? Are they stored to
    > >> -- a/some "plain" file/s outside of TB/mail system or
    > >> -- are they still part of the TB/mail system 'folder' file?
    > >> As posted also by Neil, that's a big difference how you can access the
    > >> info you need.

    >
    > > I need to handle all cases. However to be more specific the problem
    > > was noticed when I load emails from plain text/".eml" files on the
    > > local filesystem. That is the case I am trying to solve presently as
    > > the IMAP and POP cases have been operating without issue.

    >
    > > Aron

    >
    > AFAIK and as already mentioned, to read those info from the file you
    > have to parse it by yourself.
    > But at least an .eml file could be opened by TB. Try to get the msgHdr
    > from that.
    > And if possible prevent to store messages outside of TB/messenger.


    Ok I have created the following and it seems to do what I need:
    msg_hdr_for_current_msg: function( msg_uri ) {
    var mms = messenger.messageServiceFromURI( msg_uri )
    .QueryInterface
    ( Components.interfaces.nsIMsgMessageService );
    var hdr = null;

    if( mms ) {
    try {
    hdr = mms.messageURIToMsgHdr( msg_uri );
    } catch( ex ) { }
    if( !hdr ) {
    try {
    var url_o = new Object(); // return container object
    mms.GetUrlForUri( msg_uri, url_o, msgWindow );
    var url = url_o.value.QueryInterface
    ( Components.interfaces.nsIMsgMessageUrl );
    hdr = url.messageHeader;
    } catch( ex ) { }
    }
    }
    if( !hdr && gDBView.msgFolder ) {
    try {
    hdr = gDBView.msgFolder.GetMessageHeader( gDBView.getKeyAt
    ( gDBView.currentlyDisplayedMessage ) );
    } catch( ex ) { }
    }
    if( !hdr && messageHeaderSink )
    hdr = messageHeaderSink.dummyMsgHeader;

    return hdr;
    },

  7. Re: TB consistent message header from URI

    On Mar 3, 2:53*pm, Dan Mosedale wrote:
    > On 2/28/09 8:36 AM, Aron Rubin wrote:
    >
    > >>>>>>> What would get me from a message URI/URL to the message header object regardless of source

    >
    > > *[...]

    >
    > > Ok I have created the following and it seems to do what I need:

    >
    > > [...]

    >
    > Wow, that's pretty painful. *Two things that could be super helpful as
    > far as making life better for other hackers in the future:
    >
    > * documenting the current state of the world on developer.mozilla.org,
    > perhaps including the code you wrote for others to copy/paste
    >
    > * filing a bug proposing to land that code (or something like it) in the
    > Thunderbird tree, since the core code shouldn't make something so basic
    > nearly this difficult.
    >
    > Can I talk you into doing either or both of those things?


    Sure, I would be happy to do both, but this code is sadly specific to
    my use case. The missing consistent abstracted interface to get to a
    message header is obvious throughout the thunderbird code as various
    hacks are used here and there. There are two problems with your
    request. One thing is there is already a js function in the ether with
    a name that implies it does what I need - GetMsgHdrFromUri. The other
    issue is I don't understand why there is no message service for .eml
    files or why there is only a dummyHeader. Without that understanding I
    don't see how I could make a recommendation. I mean the following as a
    non-insulting genuine question: are there architecture reviews on the
    mailnews code and plans at an architecture level?

    Aron

  8. Re: TB consistent message header from URI

    On Mar 18, 10:17*pm, Dan Mosedale wrote:
    > On 3/3/09 6:06 PM, Aron Rubin wrote:
    > > On Mar 3, 2:53 pm, Dan Mosedale *wrote:

    >
    > >> Wow, that's pretty painful. *Two things that could be super helpful as
    > >> far as making life better for other hackers in the future:

    >
    > >> * documenting the current state of the world on developer.mozilla.org,
    > >> perhaps including the code you wrote for others to copy/paste

    >
    > >> * filing a bug proposing to land that code (or something like it) in the
    > >> Thunderbird tree, since the core code shouldn't make something so basic
    > >> nearly this difficult.

    >
    > >> Can I talk you into doing either or both of those things?

    > > Sure, I would be happy to do both, but this code is sadly specific to
    > > my use case. The missing consistent abstracted interface to get to a
    > > message header is obvious throughout the thunderbird code as various
    > > hacks are used here and there.

    >
    > Definitely. *I've had to hack around that myself, and unfortunately I
    > didn't have the bandwidth to do anything to track or address that
    > problem at the time.


    Ok, I will try to define an ideal.

    > > There are two problems with your
    > > request. One thing is there is already a js function in the ether with
    > > a name that implies it does what I need - GetMsgHdrFromUri.

    >
    > Indeed, I wasn't aware of that method. *Re-scanning the thread, I see
    > that you said at the beginning that some of your testers didn't have
    > that available. *Is it possible that they were using pre-2.0 versions of
    > Thunderbird?


    No, I checked that. You can view the archives of the lookout mailing
    list. This is a pitfall (at least a hole in my understanding) of JS, I
    never know what the global scoping/loading rules are. I wish they
    would fix that instead of adding more complexity through sugary
    namespace syntax.

    > > The other
    > > issue is I don't understand why there is no message service for .eml
    > > files or why there is only a dummyHeader. Without that understanding I
    > > don't see how I could make a recommendation.

    >
    > I kinda suspect it has something to do with them not having accompanying
    > .msf, but that's just a guess. *bienvenu is likely to know.
    >
    > In general, I think it's completely reasonable to file bugs and add
    > content to the wiki based on whatever knowledge you have at hand. *At
    > some level, this is just a specific case of not wanting to let the
    > perfect be the enemy of the good (or partial, or whatever :-).
    >
    > Partial documentation (including comments explaining what the author
    > didn't know) is still much better than no documentation. *Similarly,
    > filing a bug pointing out shortcomings in the current extension
    > development environment is entirely reasonable, even if it's not clear
    > at filing-time how they should be fixed.


    I have been flamed for lesser offenses on other projects I was trying
    to contribute to. I have gotten into the habit of knowing my stuff
    before writing.

    > > I mean the following as a
    > > non-insulting genuine question: are there architecture reviews on the
    > > mailnews code and plans at an architecture level?

    >
    > Historically, there haven't been. *We were hoping to do some as part of
    > the Thunderbird 3 cycle, but unfortunately that didn't happen. *It's my
    > fault for letting the work of setting those up get elbowed by other
    > work. *But those are past setbacks, we definitely want to move in that
    > direction going forward.


    Ok I am going to have to ask you to listen to your advise from above
    on this one . Something is better than nothing. Start with a
    generated flow/dependency graph and start pruning until you get
    sufficiently high level and then document. My only source of data has
    been the XULplanet docs. In particular the parts that say this object
    is passed as an to these functions and returned by these functions.
    The XULplanet docs are not up to date. When people get frustrated that
    they don't have a handle on architecture they start doing rash things
    like forking (I am not talking about myself here). I will try to help
    with the very little time that I have.

    Aron

+ Reply to Thread