[Interop-dev] Software design

[Federico Capoano]

Hey,

Il 07/04/2012 15.12, Mitar ha scritto:
> Hi!
>
>> We are indeed building something like pinax but for networks.
> 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.
>
> http://trac.edgewall.org/
>
> 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.

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

Il 07/04/2012 13.55, Federico Capoano ha scritto:
> 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.
> You can basically copy and paste one of those example project,
> configure the settings file, create the database for it with:
> *python manage.py syncdb
> *and then run the development server
> *python manage.py runserver*
> and then see it on http://localhost:8000
>
> This is really awsome, for these reasons:
>
>   * it gives you many functionalities out of the box
>   * but it doesn't force you to use them
>   * you can infact modify the example project, rename it, change the
>     design, make it something completely different
>   * you can also directly build something new from scratch using the
>     several apps available with pinax
>   * you can use additional django apps, and some interesting
>     additional django apps are developed by the pinax team
>   * 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.
>
> I think the web interfaces will have to be standalone apps, it could
> also be compared to the "example project" of pinax.
> 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.
>
> I'm taking a look at nodewatcher, I see some steps in that direction
> have been taken.
> 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.

I wrote that web interfaces could be separate apps.

>
>> 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.
> 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:
>
> http://interop.wlan-si.net/
> http://dev.wlan-si.net/

How can you know how people will want to do things? I don't think it is
predictable.
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).

>> So for that reason maybe the core apps should not contain any design
>> or user interface functionality other than skeletons.
> Design can always be overriden. I do not see the reason why we shouldn't
> provide some defaults?

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 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. :-)
>
>> so I guess it could become one of the web interfaces available for
>> the framework we will develop.
> 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.

Yes nodeshot is more a web-interface more than anything else, so it
could be integrated with some different database model.

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.

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

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 also suggest to take a look at this django ecommerce framework:
>> https://www.django-shop.org/
> Again, I know it and we will even probably use it for ourselves. But I
> think it is again centered for developers, not users.

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.

>>     /*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./
> They say it. :-)
>
>>     /*Livesettings*: Sorry./
> This is exactly the thing we would like: that users could set some
> things also through the web interface.

They're talking about the values in the settings.py that are loaded only
once.
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.

>
>>     /*Shipping and maintaining templates in the basic codebase*: This is
>>     wrong./
> 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.

So you see we kinda agree.

There's something which I haven't understood though:
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.

I thought we were brainstorming on what we could do in order to develop
this common thing.


*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/f1b9aa8c/attachment.html>