Re: [Evolution] back from Outlook

["Bharath Acharya" <abharath novell com>]

On Wed, 2008-02-13 at 08:24 -0500, Arthur S. Alexion wrote:
> On Wed, 2008-02-13 at 07:53 -0500, Bharath Acharya wrote:
> > PST import is one thing we are looking at. I am working on a plugin
> > for
> > Evolution that can import .pst files (2000 and 2003,2007 formats).
> > I've
> > it tested for Mail and Contacts importing and it works great :) 
> >
> > It will be committed in the next cycle.
>
> This is an important feature for those of us who need to use
> Auto-Archiving.  
>
> At my company, the exchange stores are backed up nightly to an offsite
> provider, an expensive endeavor.  To minimize the costs, we limit the
> amount of mail that can be left on the exchange server.  We do this
> through auto-archiving in Outlook.  The archive is stored on a raided
> drive, but no offsite backup.  Outlook users simply open the archive as
> a local PST.
>
> This has caused me problems until now because I use Evo and cannot
> access the archive.pst.  Your work should solve my problem.  There are
> some considerations I hope you address.

ïNow these are some cool requirements i must say :) ïThanks for these
considerations.

>      1. The archive grows/changes bi-weekly.  I assume your patch is an
>         import patch, not a way to look at a live PST.  While the latter
>         would be preferable, I can live with a bi-weekly import.
>      2. 
>      3. If I need to do a bi-weekly import, will it provide a "merge"
>         capability so that I can append the added data only instead of
>         creating duplicates of older data?

ïCurrently i was just looking at importing all the mails present in the
pst files. I think we can provide a merge function. I'll look into this
enhancement.

>      4. 
>      5. If it will create duplicates of already imported data, is there
>         a way to purge the previously imported data in order to
>         re-import?
>      6. 
I would support the merge capability over purging previously imported
data. But it's a good idea if we fail with the better idea ;)

>      7. Changes to imported data will not be written back to the source,
>         I presume, so I hope there is a way to make the imported data
>         read-only so that Evo users will not make changes that are
>         overwritten bi-weekly.
>
> Thanks for your work on this.


Regards,
--Bharath