Re: Evolution Plugins (Was Re: Rise of the Plugins)

[Srinivasa Ragavan <sragavan novell com>]

Sorry to join late in the discussion, just back from my vacation.

On Fri, 2007-11-16 at 11:38 +0100, Vincent Untz wrote:
> On mer, 2007-11-14 at 23:56 -0700, Sankar P wrote:
> > 2) Some plugins should not be shown 
> > 
> > This may not be possible as people may not want a functionality
> > implemented by a plugin. Disabling this plugin helps them to save
> > screen-real-estate (menu-items etc) and reduces memory foot-print. 
> > 
> > If any of the core feature is implemented as a plugin, I accept that it
> > should not be shown in the plugin-manager and will happily remove it
> > from the plugin-manager list. (It should have been core-code than a
> > plugin in the first place though) 
> > 
> > HTTP Calendars and IMAP Featuers are not core features since it may not
> > be needed by everyone. Say a corporate Evolution-GroupWise user.
> 
> Heh. Bad examples :-)

Right. Local Addressbook/Calendar are better examples for core features
as plugins. 
HTTP Calendars is debatable. IMAP features is named/described wrongly.
It just provides a feature to select the headers to download and nothing
core other than that.

> 
> I've opened the plugin list five minutes ago, to take a look. I wondered
> why there were so many "core" plugins. So, looking at both examples
> you're giving:
> 
>  + HTTP Calendars is described as "Provides core functionality for
>    webcal and http calendars.". I'm a user who doesn't know anything
>    about technical stuff: the plugin provides core functionality, so I
>    enable it. I'm a user with a technical background: "oh, there are a
>    lots of calendars on the web now, I want this to work, just in case"
> 
>  + IMAP Features is described as "A plugin for the features in the IMAP
>    accounts.". Right. I have absolutely no clue what it's supposed to
>    do. I guess evo still supports IMAP without this plugin, so why not
>    support IMAP features anyway?
> 
> Maybe 95% of the plugins of evo should not be displayed as plugins. They
> should either be preferences in the standard preferences dialog, or they
> should be enabled anyway.

95% is a bit much ;-)

> 
> This is not only true for evo, rhythmbox has the same issue (although
> there are less plugins there)
> 
> (and of course, +1 for splitting evo)

Vincent, at GUADEC 06 I demoed split. Even there was a external patch
that was floating in hackers list some time back. Unfortunately all
those break the assumptions of Evolution. There are lot more dependent
issues which needs to be addressed before split. I guess it would take a
separate release for that. The current team is focussing on
stability/performance/bugs of Evolution and MAPI based Exchange
connector. If we are out of MAPI atleast, we would definitely have more
time to do things required for split. Split itself would take pretty
less effort :-). Believe me that most of the team too understands it and
we have already done some thoughts for its dependent issues
( http://www.go-evolution.org/UAM ) and it is part of our planning as
well ( http://www.go-evolution.org/Evo2.22 ). I hope that we would have
some dedicated resources for it pretty soon.

-Srini.

> 
> Vincent
> 
> -- 
> Les gens heureux ne sont pas pressés.
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list