0

I want to search a pattern on several external websites and want a common interface to type once and gather all results in the same view. Thus, I am currently building a project which consists of a web-server (for user interface) able to send request to other websites.

I plan to use Bottle or Flask for quick underlying web-server functions and want to adopt a plugin architecture.

Since I do not know how many websites I am going to visit for now, and since the parsing will be different for each website, as well as the quantity of information, I want that every plugin addition require the least possible amount of code. Only parsing process. For example, adding a new website to visit must not require to modify all data models, views templates, etc.

So, I was thinking of a core program sending and accepting limited number of generic functions to modules. There is a limited information types for the Core, and each module is able to provide some or all those types.

My real question is the following : should I use OOP polymorphism or imp module (load_source) to use my modules?

Each module can be a class built from a generic module class, OR each module can be independant and contains functions usable by the core, calling them with imp.load_source(). The second option make me think of exporting DLL functions to use them with a C/C++ program.

I have been reading this post, really interesting, i am still wondering in my case whether subclass are better?

Thank you for your advices!

Community
  • 1
  • 1
Jean Stache
  • 15
  • 5

1 Answers1

0

Your problem is actually comprised of 2 parts:

  1. Locate available plugins and and load their sources.
  2. Initialize(i.e. configure) and utilize your plugins.

The "polymorphism" question relates to the later. So it is possible to have both of what you suggested: use imp.load_source to get a polymorphic sub-class that can configure before utilizing later the plugin.

But I would advise for the 1st part to use the "standard" mechanism of setuptools because:

  • loading plugins without conflicts or missing requirements,
  • even if the plugins themselves have other dynamic dependencies (why limit your downstream "programmers" to monolithic designs?), and
  • and keeping the list of available plugins updated as packages are installed and removed from the sys.path or plugin-dir,

are tasks closely related to the packaging and distribution system of a language. In the long run, a distribution/packaging based solution would always be a more solid choice for plugins.

If you take a peek at this exemplary application crafted for comparing various plugin architectures, you will notice that the code required is almost smaller than the rest, while it accomplishes much more.

ankostis
  • 8,579
  • 3
  • 47
  • 61