[Interop-dev] Software design

[Mitar]

Hi!

> Indeed, did you read what I wrote in my previous email:

Yes. And what I explained was that I think it should be like:

- checkout/clone
- python manage.py runserver
- open http://localhost:8000/install/
- enable/disable modules, configure/finish the installation

There could be also some step for some settings.py configuration after
cloning, but we could also do it without.

But of course, if you will not like the installer, you could after clone
disable the installer app in the settings.py, configure everything
manually, add/remove things from settings.py as you want. Use all
provided Django apps in your own/other/custom Django installation.

> I wrote that web interfaces could be separate apps.

Everything would be a bunch of separate Django apps. (Are you thinking
the same as when you say "apps"?)

And I believe Django apps (our modules) would be of different kinds:

- some which just provide some backend functionality (like parsing of
OLSR topology, reading from SNMP)
- some which will provide some frontent functionality (like map)
- some will provide both
- some extra/other

Of course also all existing Django apps could also be somewhere here.

> How can you know how people will want to do things? I don't think it is
> predictable.

We agree on this. :-)

> I think it would be best to develop something very abstract with some
> out-of-the box solutions built on top of it, so that those who are happy
> with the existing solutions can use those, while those who are not can
> build other solutions which are still based on the common framework (and
> are compatible).

We agree on this. :-)

I do not think anything of this is contradictory and cannot be achieved
at the same time?

The only important thing is that we develop in a modular and reusable
fashion.

> I want to underline that in my previous email I did not write that we
> should not provide some defaults. I suggest to read it again.

I am also not saying that you have. :-) I am just trying to show you
those tiny differences I see so that we can more talk about them. Those
other things seem we agree on.

Those tiny difference is just what you get when you clone. Do you get
some preconfigured out-of-the-box solution or do you get just building
blocks (with examples) you have to still put together. I am for the
first option, because those with more knowledge will be able to break
the out-of-the-box solution apart/reconfigure it. Especially if it is
official/provided solution.

But I think we are speaking the same. I just wanted to show you one
other project we could look upon. Which is building an *application*
based on components and not *framework* of components to be used in your
own application.

And this is maybe the difference? I am saying to build an application
where you can strip everything down, if you want, and use only building
blocks (and it has a common core), you are saying to have building
blocks with some default/example application using that.

Hm, is this really a difference? Maybe not. :-)

> What I think is that if we want to do something that all the communities
> will want to use it will have to be very flexible and abstract, because
> it's impossible to build one out-of-the-box solution that suits
> everyone's needs.

Completely agree. But initial installation could be provided. You know,
it is very good that people very fast get something to see and play
with. And then they can configure things, enable, disable, extend, adapt.

> So I tihnk that the framework approach with some out-of-the-box
> solutions ready would be the best approach.

Then we are talking the same thing?

> I think an approach to build an out-of-the-box enduser solution which
> suits everyone's needs would not work and I doubt that is even possible.

I am not saying that. I am saying of out-of-the-box example application
you get immediately when you checkout. See Trac, you install it and you
can use it. Then after starting to use it, you see that in your open
source project you would want to do something different, you go, and
enable/disable/configure a component. Or implement your own.

Similar to Drupal, it provides a framework and set of components. Nobody
is saying that initial installation will work for everybody. This is
impossible. Just that we should have one, which "just works" and is
something we see as a good starting point for future wireless communities.

Do not forget, we would like that our project is used by emerging/new
network communities. They do not yet know how to build networks, what
are their needs, what modules they want or not want, this comes when
they will start doing things. This is why I believe we should have some
default, which some best-practice suggestion how to start.

> I do want users to be able to change settings of their nodes and stuff,
> but I would prefer that the main settings of the software are stored in
> the main settings.py file and are loaded only once without need to query
> the database on each page load.

You could (as everything else) enable/disable such functionality.

> from the things you say it seems the decisions have already been made. I
> didn't understand that the development process and design of the
> software was already decided.

Of course not. :-) Silly. Then I would not be discussing it with you.
:-) I am just explaining you my vision and reasons for it. So that you
could understand them and see how they compare to your ideas. And
convince me otherwise.


Mitar