[Interop-dev] Software design

[Federico Capoano]

Hey,
> [CUT]
> 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.

It seems we agree on most things.

Few more points follow:

Il 07/04/2012 16.37, Mitar ha scritto:
> 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.

We are basically speaking about something which is very similar but we
have a slightly different approach.

While you (and also Lorenzo aka OrazioPirataDelloSpazio in the other
thread) seem to think in terms of what the result would be / would look
like 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.

I agree that it should be possible to install it and see it in action, I
didn't mean we should develop something on which you are forced to
develop on. I just like the way pinax is structured. If you check the
code inside there are several ready-to-use solutions that work, I tried
one and it was very nice starting point for developing a website but of
course our case is different, we are not developing simply a website, we
want to offer several apps to wireless communities, and we want to have
a working ready to use solution that can be a good starting point for
new communities.

>> 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.

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.

So I think that having something similar to what pinax has would be
great, they have 4 starter projects:

  * zero project
  * basic project
  * static project
  * account project

We could individuate different network setups and make few
out-of-the-box solutions.

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)

> 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.

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.

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


*Federico Capoano*
Web Designer & Web Developer
Portfolio/Blog: nemesisdesign.net <http://nemesisdesign.net>
Twitter: @nemesisdesign <http://twitter.com/nemesisdesign/>
PGP Key ID: 308BD46E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20120407/ce0afd96/attachment.html>