Re: [Evolution-hackers] Evolution.Importer.createControl

[Not Zed <notzed ximian com>]

>  
> > Isn't the progress stuff just handled in the importer itself?
> > 
> > Well it will be in the mailer anyway, whatever the rest does.
> 
> The progress stuff has been handled in the shell code I believe.  If you
> move it to the mailer maybe we should just do away with the corba bits
> as you suggested earlier, although i'm not sure how this works out with
> the intelligent importers.

Intelligent importers have always had to do their own progress reporting
(that i can tell from the code - hence my comment above, i hadn't got to
the per-file ones yet).  Actually they have to do some other weird shit,
like unref themselves when done otherwise they don't go away (shell ref
problem?  or workaround for bonobo refcounts?).  The two interfaces are
totally different, one is a synchronous call the other is this very
painful 'next step' one (the ldif importer reads everything the first
go, then adds them one at a time for each call after that - no wonder
its so slow in the gui, and provides little enhanced gui interactivity).
The only reason to have the next-step thing seems to be for progress
reporting, but since you don't know how much you have to do, it can't do
anything other than bump an activity bar anyway!  At the very least you
should pass a listener to loadFile and receive status updates till its
done/fails - but still, there seems little reason for it anyway.

I've done the same for the single importers because it was simpler -
than having to try and keep state around between calls, and handle all
the edge cases.  And I can't anyway - all the mail importing is done in
another thread now, which fixes all those gui blocking glitches too.
They have a lot more progress information at their disposal (i.e.
percentage complete).  And ... I added a cancel button too since it was
essentially free with the mail/camel thread framework.

(and yeah i did this in preparation to having the importers done
differently).

BTW I see that libdbx (oe5 ?and above?) has a command line utility
that'll dump a file to stdout as an mbox, maybe with some minor patches
(e.g. dump folder tree, dump specific folder), we could fairly trivially
write an importer that calls it in a pipe (thereby, saving code, and
also getting around having to link to it).  A future bounty?  Possibly
do the same with libpst, although it has more in it than mail.

In response to my mail on evolution@, someone suggested we make a syncml
based interface so that others could write the importers (?more?
easily?).  I guess that could be an idea, if it can support enough info
anyway (accounts, filters?, folders, etc), although the overhead of
going through XML would be extremely prohibitive for mailboxes - there
can be a LOT of data to import, and it can be slow enough going fd-
>memory->fd as it is.  Maybe another future bounty though?