<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hey,<br>
<blockquote cite="mid:4F805124.1030603@tnode.com" type="cite">
<pre wrap="">[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.
</pre>
</blockquote>
<br>
It seems we agree on most things.<br>
<br>
Few more points follow:<br>
<br>
Il 07/04/2012 16.37, Mitar ha scritto:
<blockquote cite="mid:4F805124.1030603@tnode.com" type="cite">
<pre wrap="">Hi!
</pre>
<blockquote type="cite">
<pre wrap="">Indeed, did you read what I wrote in my previous email:
</pre>
</blockquote>
<pre wrap="">Yes. And what I explained was that I think it should be like:
- checkout/clone
- python manage.py runserver
- open <a class="moz-txt-link-freetext" href="http://localhost:8000/install/">http://localhost:8000/install/</a>
- 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.
</pre>
<blockquote type="cite">
<pre wrap="">I wrote that web interfaces could be separate apps.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">How can you know how people will want to do things? I don't think it is
predictable.
</pre>
</blockquote>
<pre wrap="">We agree on this. :-)
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<br>
We are basically speaking about something which is very similar but
we have a slightly different approach.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote cite="mid:4F805124.1030603@tnode.com" type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<br>
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.<br>
<br>
So I think that having something similar to what pinax has would be
great, they have 4 starter projects:<br>
<ul>
<li>zero project</li>
<li>basic project</li>
<li>static project</li>
<li>account project</li>
</ul>
We could individuate different network setups and make few
out-of-the-box solutions.<br>
<br>
Examples (just for the sake of explaining what I mean):<br>
<ul>
<li>node map only (something like nodeshot for example)<br>
</li>
<li>network monitoring (node map + some network monitoring
integration)<br>
</li>
<li>network manager (node map + dns + firmware generator, ecc)<br>
</li>
</ul>
<blockquote cite="mid:4F805124.1030603@tnode.com" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
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.<br>
<br>
But let's not forget also the existing communities which are our
primary goal (am I right?).<br>
<br>
<div class="moz-signature"><br>
<b>Federico Capoano</b><br>
Web Designer & Web Developer<br>
Portfolio/Blog: <a href="http://nemesisdesign.net">nemesisdesign.net</a><br>
Twitter: <a href="http://twitter.com/nemesisdesign/">@nemesisdesign</a><br>
PGP Key ID: 308BD46E</div>
</body>
</html>