| Author |
|
softwareguy
Newbie
Joined: 17 July 2010
Location: United States
Online Status: Offline
Posts: 22
|
| Posted: 17 July 2010 at 8:55pm | IP Logged
|
|
|
Seems like you have to jump through a lot of hoops to get an email out of a PST. A competing product offers something as simple as:
Dim reader as PstReader = new PstReader("c:\mail.pst")
Dim msg as MailMessage = reader.GetItem(123456)
That's it! But with MailBee, you have to do quite a bit to drill down to the items in a folder and then convert from PstMessage to MailMessage.
Are there any plans to make message extraction out of a PST any simpler?
Also, it seems like the resulting MSG file is not valid, as I'm unable to open in Outlook 2010, although I have to do further testing to narrow down the potential problem...
|
| Back to Top |
|
| |
Alex
AfterLogic Support
Joined: 19 November 2003
Online Status: Offline
Posts: 2206
|
| Posted: 18 July 2010 at 3:33am | IP Logged
|
|
|
Quote:
Dim reader as PstReader = new PstReader("c:\mail.pst")
Dim msg as MailMessage = reader.GetItem(123456) |
|
|
Our approach is enumerating-based. You do not need to know anything about .PST file in order to convert it into .EML files. You let MailBee find all items and process interesting items.
It's a kinda different philosophy from your competing product. Ours is MailBee.NET Outlook Converter (Converter is a key point). It's purpose for a programmer is to extract all the required data from .PST (into .EML or MailMessage objects) and forget about it.
It's assumed that once you extracted an item (and know its ID or folder), you won't access it directly in .PST any longer.
Things you're talking about assume another approach where you're not just converting .PST file but working with it all the time (e.g. yesterday you remembered ID of an item and now you're accessing the object by this ID). This is certainly not a converter-like product.
So, the purpose of our product may just be different from what you need in your particular case.
Quote:
| Also, it seems like the resulting MSG file is not valid |
|
|
You mean you extracted MailMessage and then used MsgConvert to convert it into .MSG and it does not open in Outlook 2010?
Regards,
Alex
|
| Back to Top |
|
| |
softwareguy
Newbie
Joined: 17 July 2010
Location: United States
Online Status: Offline
Posts: 22
|
| Posted: 18 July 2010 at 7:13am | IP Logged
|
|
|
Alex wrote:
Our approach is enumerating-based. You do not need to know anything about .PST file in order to convert it into .EML files. You let MailBee find all items and process interesting items.
It's a kinda different philosophy from your competing product. Ours is MailBee.NET Outlook Converter (Converter is a key point). It's purpose for a programmer is to extract all the required data from .PST (into .EML or MailMessage objects) and forget about it.
It's assumed that once you extracted an item (and know its ID or folder), you won't access it directly in .PST any longer.
Things you're talking about assume another approach where you're not just converting .PST file but working with it all the time (e.g. yesterday you remembered ID of an item and now you're accessing the object by this ID). This is certainly not a converter-like product.
So, the purpose of our product may just be different from what you need in your particular case. |
|
|
Thanks for the explanation as to the difference in functionality. How hard would it be to add this ability? There is a strong business case to be made here with being able to just work with the PST, such as in mail archival/retrieval systems where you don't want to be actually extracting out all the messages. You want to leave everything nice and contained within the PST and only extract particular emails when needed based on prior knowledge of the "id".
Alex wrote:
| You mean you extracted MailMessage and then used MsgConvert to convert it into .MSG and it does not open in Outlook 2010? |
|
|
Yep. However, something else may have gone wrong with the resulting file so I'll have to do some more definitive testing to be sure. I'll let you know later.
|
| Back to Top |
|
| |
Alex
AfterLogic Support
Joined: 19 November 2003
Online Status: Offline
Posts: 2206
|
| Posted: 18 July 2010 at 8:47am | IP Logged
|
|
|
Well, our Outlook Converter product is one of the most rapidly evolving members of MailBee.NET Objects suite so I assume we'll probably add the functionality you're talking about in one of upcoming releases within a few months range (in v6.2 or v6.3). But this depends on whether it will effectively work with the underlying implementation (which is stream-based and needs to read elements from the first one to access N-th one).
Regards,
Alex
|
| Back to Top |
|
| |
softwareguy
Newbie
Joined: 17 July 2010
Location: United States
Online Status: Offline
Posts: 22
|
| Posted: 18 July 2010 at 3:39pm | IP Logged
|
|
|
I really think this would be a great feature, not just for me but other customers. I'm sure there is a need to extract only particular messages as needed and it needs to be relatively fast.
Although I have to admit that your product is MUCH faster than competing product in getting list of folders and items from a large PST (~3GB). Yours takes mere milliseconds (competing product is seconds). But, their product can extract a particular MSG out of that large PST in a blink of an eye based on an already known ID. I'm also trying to figure out what that ID is as it is not visible in your product for some reason. It is always an integer, no text.
So I'm kind of torn here at the moment. We're still in development stages, so we have some time until go live, but really we can't use too different products for this. However, if I were to pick what is more important, it would be the MSG extraction because that will happen more N-times by N-users, where the initial iteration through the PST only happens once to index it, so taking a hit up front is much better than over and over later.
|
| Back to Top |
|
| |
Alex
AfterLogic Support
Joined: 19 November 2003
Online Status: Offline
Posts: 2206
|
| Posted: 18 July 2010 at 3:51pm | IP Logged
|
|
|
That's exactly what I was talking about. Ours and competing products use different methods to extract data and I'm not sure if it's possible to hit both targets with any of these methods. Ours is streamlined, it can process the entire file quite fast. However, random access to any place is not possible. Competing product can provide random access in expense of speed of streamlined access.
So I'm really afraid of significant performance degradation in case of providing random access feature. It's all subject to serious research of this matters so I can't really promise you anything here. It's not an easy and simple feature to add, it's not even yet known what side effects of this feature will be.
Regards,
Alex
|
| Back to Top |
|
| |
softwareguy
Newbie
Joined: 17 July 2010
Location: United States
Online Status: Offline
Posts: 22
|
| Posted: 18 July 2010 at 4:55pm | IP Logged
|
|
|
How about a compromise? How about introducing a new method, or class, or whatever, that deals only with item extraction from a PST based on "the id" that was obtained earlier while iterating through the PST with your PstReader class? I don't see how that would degrade performance of your existing classes as this would be entirely separate.
|
| Back to Top |
|
| |
Alex
AfterLogic Support
Joined: 19 November 2003
Online Status: Offline
Posts: 2206
|
| Posted: 19 July 2010 at 3:08am | IP Logged
|
|
|
Everything's possible, of course. It just takes much time. It takes time to find out if the current engine can be adapted, it takes time (a hell lot of time) to create a new engine if the first research "returns false" and seamlessly plug it in, etc. We would have of course done this at the first place if this were the only feature ever needed. Still, we have to compare the amount of R&D efforts and the possible benefit for every new feature. And we have a number of other very anticipated features in the to-do list (like HQ HTML-to-RTF converter), and if it turns out that another (and also long-awaited by many customers) feature is much more easier and faster to implement, we'll prefer to go this way and put aside the first feature. Due to this, I can't actually tell anything for sure since we ourselves don't have all the information yet.
Regards,
Alex
|
| Back to Top |
|
| |
MailBee.NET Objects 
MailBee.NET Queue 
MailBee Objects 
WebMail Pro PHP 
AfterLogic Aurora 
MailSuite Pro for Linux 
Unified Messaging Solution 
Search
Register
Login
Topic: Why so hard to get MailMessage from PST?
Privacy policy |
Refund policy