<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hey,<br>
<br>
Il 07/04/2012 15.12, Mitar ha scritto:
<blockquote cite="mid:4F803D53.3040302@tnode.com" type="cite">
<pre wrap="">Hi!
</pre>
<blockquote type="cite">
<pre wrap="">We are indeed building something like pinax but for networks.
</pre>
</blockquote>
<pre wrap="">
Great example, but I am not so sure if this is what we would like to
build. I have idea of building more like Trac for network.
<a class="moz-txt-link-freetext" href="http://trac.edgewall.org/">http://trac.edgewall.org/</a>
Like Trac is for developing open source projects (you install it and it
helps developing them), our project would be for deploying open networks.
I think that Pinax is in some way a meta-framework, providing many
functionalities included when you want to build your own web site. But
you still have to develop something.
I would like more that our projects is a standalone application already
(like Trac), but which is heavily customizable/pluggable/themable.
So that you can install it and you immediately get some basic things
working. Then you configure it (could maybe even through web interface)
and adapt it to your needs, but that maybe even defaults are already
good enough for you.</pre>
</blockquote>
<br>
Indeed, did you read what I wrote in my previous email:<br>
<br>
Il 07/04/2012 13.55, Federico Capoano ha scritto:
<blockquote cite="mid:4F802B44.9020300@nemesisdesign.net"
type="cite"><font face="Helvetica, Arial, sans-serif">But how can
you see how it works if it doesn't have any html templates? Here
it comes the interesting thing, Pinax includes also a set of
example projects that are out of the core, these example
projects include also html templates, with a clean design and
some basic user interface functionalities.</font><font
face="Helvetica, Arial, sans-serif"><br>
You can basically copy and paste one of those example project,
configure the settings file, create the database for it with:<br>
<b>python manage.py syncdb<br>
</b>and then run the development server<br>
<b>python manage.py runserver</b><br>
and then see it on <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://localhost:8000">http://localhost:8000</a><br>
<br>
This is really awsome, for these reasons:<br>
</font>
<ul>
<li><font face="Helvetica, Arial, sans-serif"> it gives you many
functionalities out of the box</font></li>
<li><font face="Helvetica, Arial, sans-serif">but it doesn't
force you to use them</font></li>
<li><font face="Helvetica, Arial, sans-serif">you can infact
modify the example project, rename it, change the design,
make it something completely different</font></li>
<li><font face="Helvetica, Arial, sans-serif">you can also
directly build something new from scratch using the several
apps available with pinax</font></li>
<li><font face="Helvetica, Arial, sans-serif">you can use
additional django apps, and some interesting additional
django apps are developed by the pinax team</font></li>
<li><font face="Helvetica, Arial, sans-serif">you don't loose
compatibility with the basecode. By using the example
projects you are infact not modifying pinax's code. When a
new version comes you just update the core of pinax
hopefully it will still work.<br>
</font></li>
</ul>
<font face="Helvetica, Arial, sans-serif">I think the web
interfaces will have to be standalone apps, it could also be
compared to the "example project" of pinax.<br>
It's very possible that different communities might develop
different web interfaces. So for that reason maybe the core apps
should not contain any design or user interface functionality
other than skeletons.<br>
<br>
</font><font face="Helvetica, Arial, sans-serif">I'm taking a look
at nodewatcher, I see some steps in that direction have been
taken.<br>
Nodeshot instead is a monolithic piece of code, not abstract at
all. It focuses more on the user interface, so I guess it could
become one of the web interfaces available for the framework we
will develop.</font></blockquote>
<br>
I wrote that web interfaces could be separate apps.<br>
<br>
<blockquote cite="mid:4F803D53.3040302@tnode.com" type="cite"><br>
<blockquote type="cite">
<pre wrap="">Why no html templates? Because not everyone wants the same template,
same design, same functionalities. Also the plugins you choose determine
your design so it is not possible to make an html template that is good
for every case.
</pre>
</blockquote>
<pre wrap="">
I don't think this is really a problem. Why wouldn't you like same
templates? In most cases you just want to override logo and colors and
this is it. So change CSS a bit and it works. Look:
<a class="moz-txt-link-freetext" href="http://interop.wlan-si.net/">http://interop.wlan-si.net/</a>
<a class="moz-txt-link-freetext" href="http://dev.wlan-si.net/">http://dev.wlan-si.net/</a>
</pre>
</blockquote>
<br>
How can you know how people will want to do things? I don't think it
is predictable.<br>
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).<br>
<br>
<blockquote cite="mid:4F803D53.3040302@tnode.com" type="cite">
<blockquote type="cite">
<pre wrap="">So for that reason maybe the core apps should not contain any design
or user interface functionality other than skeletons.
</pre>
</blockquote>
<pre wrap="">
Design can always be overriden. I do not see the reason why we shouldn't
provide some defaults?
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:4F803D53.3040302@tnode.com" type="cite">
<pre wrap="">I thing Pinax is too low level. It is not meant as end-user application.
I think that we want to develop end-user (new community wanting to
deploy a network) application, which would still allow customization for
different needs for different networks. But allow it, not require it. :-)
</pre>
<blockquote type="cite">
<pre wrap="">so I guess it could become one of the web interfaces available for
the framework we will develop.
</pre>
</blockquote>
<pre wrap="">
At initial phase, I would move the whole nodeshot as one module of our
new platform. Just change it to store data in common (core) way.
</pre>
</blockquote>
<br>
Yes nodeshot is more a web-interface more than anything else, so it
could be integrated with some different database model.<br>
<br>
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.<br>
<br>
So I tihnk that the framework approach with some out-of-the-box
solutions ready would be the best approach.<br>
<br>
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.<br>
<br>
<blockquote cite="mid:4F803D53.3040302@tnode.com" type="cite">
<blockquote type="cite">
<pre wrap="">I also suggest to take a look at this django ecommerce framework:
<a class="moz-txt-link-freetext" href="https://www.django-shop.org/">https://www.django-shop.org/</a>
</pre>
</blockquote>
<pre wrap="">
Again, I know it and we will even probably use it for ourselves. But I
think it is again centered for developers, not users.
</pre>
</blockquote>
<br>
Indeed I didn't mean we should blindly follow that approach, but
think about doing a core framework with a philosophy similar to that
one, and then building few out-of-the-box solutions on top of it so
that everybody can start playing with it.<br>
<br>
<blockquote cite="mid:4F803D53.3040302@tnode.com" type="cite">
<blockquote type="cite">
<pre wrap=""> /*For developers*: Django-Shop will not be an "out-of-the-box" shop
solution. People will have to write templates for it. Shipping an
example shop is not out of the question, but it must be well
separated from a code perspective./
</pre>
</blockquote>
<pre wrap="">
They say it. :-)
</pre>
<blockquote type="cite">
<pre wrap=""> /*Livesettings*: Sorry./
</pre>
</blockquote>
<pre wrap="">
This is exactly the thing we would like: that users could set some
things also through the web interface.
</pre>
</blockquote>
<br>
They're talking about the values in the settings.py that are loaded
only once.<br>
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.<br>
<br>
<blockquote cite="mid:4F803D53.3040302@tnode.com" type="cite"><br>
<blockquote type="cite">
<pre wrap=""> /*Shipping and maintaining templates in the basic codebase*: This is
wrong./
</pre>
</blockquote>
<pre wrap="">
For framework, Django Shop is a e-commerce framework, not application.
Thank you for very good and constructive question. I think we should
really understand what we are doing. And I have a bit different view. I
don't see it as completely opposing, just as an extension: we will have
things very modular (in a Django compatible way), but we should on top
of this modularity provide some out-of-the-box solution. I do not see a
reason why not? If we would be developing an application framework,
maybe, but we are not developing that, but a network framework.
</pre>
</blockquote>
<br>
So you see we kinda agree. <br>
<br>
There's something which I haven't understood though:<br>
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. <br>
<br>
I thought we were brainstorming on what we could do in order to
develop this common thing. <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>