Standard interfaces [Was: 2.4 Proposed Modules - GnomeMeeting]

[Sean Middleditch <elanthis awesomeplay com>]

On Wed, 2003-05-07 at 15:56, Robert McMeekin wrote:
> On Wed, 7 May 2003, Sean Middleditch wrote:
> > Personally, I'd say a PIM solution is more important that just e-mail.
> > Several different apps may want access to address books or whatnot - a
> > solid framework for that which all apps can utilize seems more useful.
> > Just like having a solid HTML rendering framework (GRE, gtkhtml,
> > whatever) is more important than the browser itself (given the browser
> > needs said framework).
> 
> This seems to me like a *great* idea. I don't post to the list because I'm
> not a gnome-hacker (just a user), but I hope this gets seen through to the
> end. If there is anything a novice can do to help in this aspect, please
> let me know! :)

The basics of the idea I had I posted in a bug, here

 http://bugzilla.gnome.org/show_bug.cgi?id=110205

I doubt I explained it clearly enough, but then, I don't really know
Bonobo that well at all.  ^^;

Putting it in OO terminology, GNOME should define some abstract
interfaces; the actual component used then is irrelevant.  But these
interfaces should offer tons of flexibility to the app author - pretty
much, define a method for every conceivably useful function they might
need on the implementation end.

The example in the bug is for apps that want to compose and send e-mail
(bug-buddy, app registration, whatever); any non-MUA currently has to
rely on the sendmail binary, which might not in any way shape or form be
configured to actually send mail (especially on your average desktop - I
don't even have any machines left that have an MTA set up to deliver
mail across the network...)  With an interface implemented as a
component by an MUA, the MUA could send the mail for an application.

Address books could be similar; standard methods for searching and
editing an addressbook.  Also browsers; an app should be able to get a
"browser session", and ask to open urls or (in very basic ways)
manipulate windows.  This would be _excellent_ for Evolution,
gnome-terminal, and others that want to open links in browser windows -
the current "run some funny command using exec()" is disgusting, and
wholly inflexible.

The hard part is security; one doesn't want rampant processes to be able
to access an address book and delete entries.  Especially with things
like the Mozilla framework having possible Bonobo interfaces.  Things
like sending mail are somewhat easy (popup a dialog, "app xys wants to
send a mail to foo.  [Edit] [Cancel] [Send]")

On a similar line, a standard set of gconf keys for user info would be
great.  Something like Name/Phone/E-Mail/etc.  These could be used even
in apps that have their own config; the new account druids in Evolution
for example could use these values as the default entries.  So even if I
have to have several apps that need to store the info on their own, at
least "registering" with the app is quick and easy (just hit Accept or
whatever, it's all filled out already).

Dunno, maybe I just have no idea what I'm talking about (happens often
enough), but does this not seem like a good idea?  Definitely not 2.4
material (it needs both a solid interface defined, plus at least one app
for each interface that actually implements the component), but maybe
for 2.6 or beyond...

It would also help a ton with the default apps configuration that is
aweful now.  For "default browser", it could just list all component
that implement the gnome browser interface.  Wrapper components could be
used for "legacy" apps (like people who want to use Mutt for mail, or
Mozilla for browsing, or whatever - they'd implement the
method/interfaces using the command line calls, which obvious reduced
functionality/flexibility).

> 
> > --
> > The pain of war cannot exceed the woe of aftermath.
> >   -- Led Zeppelin, "Battle of Evermore"
> --
> Robert McMeekin (viper)
> mailto:viper mcmeekin info
> http://rob.mcmeekin.name
-- 
The pain of war cannot exceed the woe of aftermath.
  -- Led Zeppelin, "Battle of Evermore"