[Interop-dev] Software design

[Mitar]

Hi!

> I am more concentrated in finding out what is the best way to
> structure the code and the database, because I know every community will
> want to do something slighlty different with it and if the code
> structure and the database won't be abstract and flexible this won't be
> possible.

Aha. OK.

This is harder to explain than the "look". I agree it is the most
important thing. I will just explain how I see it currently.

Also this is why I said that Trac could be maybe a better application to
check because it has some of the features I am explaining.

So for database layer, I believe something like it is implemented in
nodewatcher registry branch should provide with good enough
extensibility. We will see when we will start porting things to it. It
allows both data and code extensibility for data models and also how
interface is generated on top of it.

http://dev.wlan-si.net/wiki/Nodewatcher/Registry

Then because all functionalities will be independent Python
modules/Django apps, we will use this for enabling/disabling different
features.

Django apps then have static and templates folder, you can override in
your site installation. This will allow basic customizability of the
interface.

Our core will also have hooks into which other modules could hook in
(and modules themselves could define additional). This is for example
nicely done in Trac.

For example, you could have a hook for main menu. Each module could then
add to it entries. Then you will also be able to order them and say
which entry should be the default one. Through templates and CSS you
will be able to style it.

Then you have another menu which is a list of actions you want to
support on the node. Modules would be able to add those actions into the
menu. Where and how this menu is displayed, then depends on your
interface you decide for.

And so on and on. Probably core will define only small set of such
hooks. But other modules will be able to define more.

> Yes agreed, we will just have to pay attention on how many components we
> add into the core because the less core components, the easier to
> understand.

I agree.

I would have three parts:

- core (database layer mostly, pluggable architecture)
- modules (few basic functionalities we believe are often needed, but
could also be turned off)
- extra (other modules somebody is willing to regularly maintain and are
probably used in at least one community and we agree that it could be
useful to others)

Also independent parts (simply, Python packages, Django apps) could be
used, so if somebody wants something special, you could develop it and
add it to your installation.

> Examples (just for the sake of explaining what I mean):
> 
>   * node map only (something like nodeshot for example)
>   * network monitoring (node map + some network monitoring integration)
>   * network manager (node map + dns + firmware generator, ecc)

I would have this as options in web-based installation? You open and it
asks you what you want to use all, you click, and this is it?

But good examples.

> In this case especially it should be possible for them to see various
> different type of solutions so they can choose which one is the best for
> them to start. They might not be able to understand all the components
> used in an advanced installation for example.

We will then have to make them understand, explain to them, etc. I do
not see any difference in proposing them a list of modules or giving
them pre-set configuration with different lists of modules. In any case
they will have to understand what those modules are. :-)

But I think we are now discussing something very far away. First we
should have some modules ready, something we ourselves can run
(configured through settings.py with enabling/disabling Django apps).
Then we can think of how to make this more user-friendly and easier to
install. Do you agree?

> But let's not forget also the existing communities which are our primary
> goal (am I right?).

But they will probably know how to configure everything according to
their needs (we just have to make sure it is configurable enough).


Mitar