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



On Thu, 2007-11-15 at 13:58 +0530, Sankar P wrote:
> On Thu, 2007-11-15 at 07:22 +0000, Philip Withnall wrote:
> > We currently have the other extreme: several different applications
> > each
> > have their own take on the address book (and then each have their own
> > different ways of integrating/syncing it with e-d-s). Why not just
> > have
> > one desktop-wide address book (I'm thinking Soylent here), and have
> > the
> > mail application use that instead? This would give us the opportunity
> > to
> > swap out the address book application in favour of other things if
> > necessary, such as an application which would use some web service as
> > an
> > address book.
> 
> 
> I am not much aware of what Soylent is. So I cannot comment about using
> that atm. However, evolution-data-server is the system-wide address-book
> that will answer your needs. IIRC, eds exposes a dbus interface which
> can be consumed by any of the desktop applications, say Contacts,
> Gnome-calendar, OpenOffice, etc. Evolution-Addressbook (not eds) is just
> another client for the evolution-data-server addressbook. Probably Ross
> Burton can explain in more detail. 

My poor knowledge of e-d-s' architecture is showing here; I believed it
stored everything, including e-mail, but apparently it only stores the
address book, calendar and tasks. However, my point still applies in
that e-d-s deals with too much, and so is wasteful if you're only using
the address book. Even so, something's still wrong, as applications
which use e-d-s for the address book still seem to be storing wrapper
data themselves. Maybe that's just Pidgin being not-properly-integrated,
though.

Soylent[1] is a cool "people browser" application Travis Reitter's
writing, and I think it would be a good way to centrally manage all your
contacts, rather than managing e-mail addresses and other details in
Evolution, IM details in Pidgin/Empathy, VoIP details in Ekiga, etc.

> > > IMHO a better approach will be to make the user choose what
> > components
> > > he want to see in his Switcher. Say if someone wants to use only
> > Mailer
> > > and Address-book, do not bother showing the Calendar component in
> > the
> > > switcher.
> > 
> > But that's effectively like turning the components into plugins, and
> > then disabling some of them; it comes back to the problem that core
> > functionality shouldn't be in plugins, and you might as well split off
> > such plugins into separate applications.
> > 
> > > Atleast for me, It will be far more useful than launching two or
> > three
> > > applications everyday morning (Mail/Calendar/Tasks)
> > 
> > Isn't that what your startup programs list is for? :-P
> 
> 
> Yeah. I should have made it a little elaborate. Everytime I (or any
> corporate user) launches evolution, what I want to do with that is:
> 
> -> Send/receive mails
> 
> -> Accept/Decline/Schedule appointments
> 
> -> Mark the tasks that I have completed, so my boss knows if it is worth
> paying me for.
> 
> 
> In addition to these basic activities sometimes I may be publishing my
> calendar etc. 
> 
> All these activities adhere to the Communication aspect of an office
> worker. And I do this atleast 4-5 times a day. Rest of the times I spend
> on gnome-planner, OO, vi etc. So opening three applications for this
> communication aspect, each time, may not be an appealing option.
> 
> I do not say that it is bad/evil to split applications but IMHO it may
> be a better idea to have Gnome applications aligned/coupled on the lines
> user behaviors, bringing similar applications in a shell, but
> very-loosely tied. In the same way how OO has a Spreadsheet, Doc-writer,
> Presentation-tool. Just my 0.001 Paisa(1). though :)

I wouldn't be against having some sort of wrapper for the various new
applications akin to the current Evolution, as I see the need for that
sort of thing. I suppose it would just be a thin application which
embeds the others.

Regards,
Philip

[1] http://live.gnome.org/Soylent

> > 
> > Regards,
> > Philip

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]