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

[Sankar P <psankar novell com>]

On Sun, 2007-11-18 at 00:15 +0530, Srinivasa Ragavan wrote:
> Sorry to join late in the discussion, just back from my vacation.
> 
> > > 
> > > 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.

IMAP Features has been named so as to align with the rest of the
providers. We have groupwise-features and an exchange-operations plugin.

For provider specific features that cannot be part of Camel (Evo's Mail
Library), we started writing plugins. The plugin list was getting
lengthy, say we had plugins for shared-folder, GroupWise-proxy,
GroupWise/Exchange Send Options, Groupwise/Exchange message retract. 

For an IMAP user any plugin related to GroupWise, Exchange or other
providers makes no sense and he will be annoyed on seeing such a lengthy
plugins list. So except for account setup, all plugins that are specific
to backends were consolidated. And thus we had groupwise-features and
exchange-operations plugins instead of a plugin for each feature. 

In the same way, any feature that is written as a plugin and specific to
IMAP will be part of IMAP features plugin.

The plugin descriptions may be improved describing what are the features
offered by the provider-specific plugins, though.

> 
> > 
> > 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.

Initially, they were part of the main preferences only, for seamless
integration. But we were getting numerous issues with the main
preferences getting bloated to the extent, that it you may need an extra
search tool for finding the option you want. And some confusions like:
Automatic-contacts belongs to mails-prefs. or contacts prefs. etc..

So I looked at what some other applications have (rhythmbox one of my
favs.) and found the Configure within plugin-manager to be highly useful
and hence did that for Evolution as well.

I am glad to hear that you use 95% of plugins, so frequently, that you
want them always enabled. But some users feel that they do not need some
plugins. Hence we have been forced to show them in the plugin-manager so
that those users can disable it.

I will be happy to remove off a few plugins from the plugin-manager if
they are really so core features. Sadly, IMAP features / HTTP Calendars
also do not belong this category as a corporate GroupWise / Exchange
provider is not likely to use any of these. 

We can add a uninstall option (perhaps with a ban option for future
upgrades) so that users do not want to see/use some plugins can never
have them in their machine/plugin-manager.


> 
> 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.

As mentioned in the above link long-back,  I am still unclear on how UAM
can prevent UI SPlit and why we need both of them. Perhaps we will take
that discussion in evolution-hackers or wiki before working on this
task; as usual.

> 
> -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
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
-- 
Sankar P