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

[Srinivasa Ragavan <sragavan novell com>]

On Mon, 2007-11-19 at 13:48 +0530, Sankar P wrote:
> 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.
> 

One of the reasons, you told that 'Just create a account then you can
see addressbook'. 
The main reason is that accounts are tightly coupled with Mail and one
has to start mailer to create accounts and start individual apps to use
it. Why can't accounts be managed central to Evolution/GNOME and all the
individual apps based on EDS can use it independent of mail. UAM is
about that. Anyways, lets move the discussion to e-h/later.

-Srini