I proposed this on the 2.24 planning page.  I'll assign the task to you then, Milan.  Do try to keep the page up-to-date with your progress.

http://www.go-evolution.org/Evo2.24

eh, page?

milan, please also keep the status of http://live.gnome.org/GioPort updated. yes, you will likely need a wiki account for this. ;-)

errr...

Changes in eds, namely in camel_stream_vfs impacts changes here in evo, thus depending on the eds bug #526741.

I have some plans for EAttachment and EAttachmentBar (bug #516933).
Just mentioning it here so we don't step on each other.

Just in case you wonder what's the progress on this, then I have a compilable version, with working download of attachments (I didn't do it as you want, Matt, only because of an async mess there, but feel free to improve it). I will test it as much as I can on Monday and will try to upload it as soon as I'll finish it (with the publishing too).

I know now that there are some parts which I'm not able to properly test, like free/busy information download in e-meeting-store (which I kept non-cancellable as it was before). There is still one thing to finish, a publishing of the information. I'm sorry to say but I expect some bugs introduce after the change. 

One question about asking for a password with publishing, we ask only for a password, but the original concept asks for domain, user name and password. What do you think about this?

Created attachment 109236 [details] [review]
proposed evo patch

for evolution;

Notes:
I tested download of remote files to composer's attachment bar, and finally also a calendar publishing to my authenticated FTP server, and both works as long as gvfsd is running. Otherwise it claims on missing service.

mail/em-vfs-stream.h/.c was removed (and should remove from svn when committing), because not used anywhere.

mail/em-format-html-display.c dropped some bonobo related mess, which used deprecated gnome_vfs functions.

e-util/e-util.h added some public functions

About that publish calendar, as I tested that, it mounts the volume when necessary, and unmounts it when was mounted by itself, otherwise just writes there.

There are also some TODO notes, because mime_type and gio's content_type are not the same thing on Win32, thus there will not work properly some parts of this. I added a bug against gio already, with proposed patch too. (bug #527175)

Milan, looks really good.  A few comments:

  - In the FULL_GNOME_DEPS line in configure.in you have gconf-2.0 listed
    twice.  Typo maybe?

  - In emp_apps_open_in() you need to pass g_app_info_launch() a list of
    GFile objects, not a list of path strings.

  - Consider adding something like this to e-util:

       GList *
       e_util_get_apps_for_type (const gchar *content_type,
                                 const gchar *optional_filename);

    Would return a list of GAppInfos.  Allow the filename argument to be
    NULL.  I'm thinking it could replace a lot of places where you have to
    check for TNEF attachments or call e_util_guess_mime_type().

(In reply to comment #9)
> Milan, looks really good.  A few comments:
> 
>   - In the FULL_GNOME_DEPS line in configure.in you have gconf-2.0 listed
>     twice.  Typo maybe?

Yup, a typo, I didn't check it properly, I'm sorry for that.

> 
>   - In emp_apps_open_in() you need to pass g_app_info_launch() a list of
>     GFile objects, not a list of path strings.

Err, I do not know why I thought it means file names. OK, I will fix it.

>   - Consider adding something like this to e-util:
> 
>        GList *
>        e_util_get_apps_for_type (const gchar *content_type,
>                                  const gchar *optional_filename);
> 
>     Would return a list of GAppInfos.  Allow the filename argument to be
>     NULL.  I'm thinking it could replace a lot of places where you have to
>     check for TNEF attachments or call e_util_guess_mime_type().

I'm not sure with this, I tried to avoid copying of the code in this patch, but if it's "only" on two places, then it doesn't matter much for me. If it would be more... :)

Are you fine if I just make those two fixes in a patch and commit it or do you want an updated patch here? I think it doesn't worth it much, because it's really long patch.

It's only two places, so I'll leave it up to you.  I was just trying to reduce the number of places we have to check for that TNEF thing.  But no big deal.

No need for an updated patch.  Fix the first two items and commit.

Can I say it now?  Awesome work!  :)

Committed to trunk. Committed revision 35378.

> Can I say it now?  Awesome work!  :)
Hehe, thanks. :)