bug-myserver
[Top][All Lists]
Advanced

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

Re: [bug-myserver] plugins management reorganization


From: Giuseppe Scrivano
Subject: Re: [bug-myserver] plugins management reorganization
Date: Wed, 15 Oct 2008 00:03:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

"Daniele Perrone" <address@hidden> writes:

> Hi everybody!
> I'm working on the reorganization of the plugins management, as i said
> on savannah (https://savannah.gnu.org/task/?8756), i want to remove
> the logic separation of plugins. To reach this goal i have to rewrite
> and refactor a lot of code, so I want to define a new interface
> between myserver core and plugins, a real OOP interface that
> simplifies the work to plugin programmers and gives more control over
> what plugins can do and how they can do it. My idea is to work around
> the event notification system, but now it seems to be a little bit
> hidden in the code, then i think it should be pointed up before work
> on plugins management.
>
> So, what do you think about it?

Simplify the plugins management system is a good thing.  I think the
best way to proceed is to completely remove any other category of
plugins and leave only what now is "generics".  The functions exported
by the plugins will be exactly what now "generics" is using, nothing
more, nothing less.
This will bring to:

1) easier APIs for MyServer to handle it.
2) Better object oriented plugins.

Any plugin will be a class, in this way the load function will have only
to register it to the right manager.
Imagine a protocol exported by a plugin:

class MyNiceProtocol : public Protocol {...} myNiceProtocolInst;

The load function will be just:

int load (...)
{
  server->protocolsManager.add (&myNiceProtocolInst);
}

The previous plugins design wanted to map a C++ class directly to a
dynamic library.  This is the reason that now there are many categories,
because any category is related to a class.  The old approach showed two
disadvantages: difficulties to handle them inside MyServer and
especially the need to change APIs everytime the respective class is
changed.

Keeping only a minimum APIs for plugins will reduce redundancy of
information, since the definition of a class will not be propagated to
the APIs.

Giuseppe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]