Date: Sat, 8 Dec 2012 19:02:52 +0200 (EET)
From: Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi>
To: Oliver Loch <o.loch@gmx.net>
cc: "alpine-devel@lists.alpinelinux.org" <alpine-devel@lists.alpinelinux.org>,
        "acf@lists.alpinelinux.org" <acf@lists.alpinelinux.org>
Subject: Re: [alpine-devel] Ideas for a new config framework, ACF2
In-Reply-To: <0467883F-A7E4-4156-940E-9F5F10AD5FB2@gmx.net>
Message-ID: <alpine.LFD.2.02.1212081711140.8590@kunkku.net>
References: <20121129152317.69585a4f@ncopa-desktop.alpinelinux.org> <201212022211.23812.vkrishn4@gmail.com> <alpine.LFD.2.02.1212050955390.22932@kunkku.net> <201212051939.19111.vkrishn4@gmail.com> <0467883F-A7E4-4156-940E-9F5F10AD5FB2@gmx.net>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
Precedence: list
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

On Wed, 5 Dec 2012, Oliver Loch wrote:

> have a look at the FreeNAS WebUI. They used Django=20
> (=A0https://www.djangoproject.com/=A0) together with DoJo=20
> (http://www.dojotoolkit.org=A0).

Django is a very nice framework for web applications. To be frank, several =

aspects in our architecture proposal were influenced by some elegant=20
design choices in Django. However, there are several reasons for not using =

Django as part of ACF. As you mentioned, one of them is the large=20
footprint. The basic Python and Django packages have a combined footprint=20
of 40 megabytes on my Fedora machine, but this is not the only downside.

You wrote that Django makes database access completely transparent. This=20
is true to the extent that you don't need to deal with SQL statements, but =

the fact is that Django is tied to SQL databases only. If you look at=20
Django's model API, it is quite evident that you really cannot enhance it=20
to support non-relational backends.

There are some relatively small SQL databases, such as SQLite (used by=20
FreeNAS, 716 kilobytes on my machine), but this is not the main issue with =

SQL. Most Linux applications read their configuration from files in /etc,=20
not from an SQL database, which means that you need to generate the files=20
from the database contents. I am not impressed at all about the way chosen =

by FreeNAS developers. They have included the generation code into the=20
init script of each service (in /etc/rc.d). Embedding SQL queries and=20
configuration file blocks to shell scripts is not nice in my opinion.

Were I to design a Django-based configuration system, I would probably use =

Django's template system to generate the files. (The template language is=20
not constrained to HTML, even though that's the typical use case.)=20
Nevertheless, we can do better with the proposed design for ACF. The=20
design is not limited to SQL but can also use e.g. Augeas as a storage=20
backend. Augeas implements a bidirectional translation between a=20
configuration file and a tree-structured data model, allowing the user to=20
directly edit the native configuration files of services. Without a=20
bidirectional translation, your manual changes would be overwritten by the =

configuration system. This would be very annoying e.g. when for some=20
reason the system does not support the option you need.

Comparing with the architecure we proposed, Django is also inferior with=20
respect to handling concurrent changes. If enabled, Django's transaction=20
middleware ensures that all database requests related to a single HTTP=20
request fall into a single database transaction. This is not sufficient to =

prevent loss of changes when two users edit the same data. There is an=20
add-on package called django-locking, but it is not really transparent to=20
module developers if multiple model instances are involved in the=20
transaction. In contrast, we propose a protection mechanism which is=20
completely transparent to module developers.

Some ACF use cases require streaming status information back to the client =

as the operation progresses. Django does not support this very well, at=20
least in any production release. (Version 1.5 will have=20
StreamingHttpResponse class.)

Finally, remember that Django is a framework intended for implementing=20
relational database-oriented web applications with server-side HTML=20
templating. While it would be possible to implement CLI and SNMP=20
interfaces for Django models, the framework does not really help in that=20
effort. We also want to include dynamic state information e.g. from /proc, =

but Django does not help there at all. I think it is better to design the=20
framework to take these use cases into account at model API level. As I=20
said, Django is a nice framework for the purposes it was designed to and=20
obviously has been developed by smart programmers. We will indeed let its=20
design influence ours. Even if we decide to implement the web interface as =

a single page application (in JavaScript), we can apply some principles=20
found e.g. in Django's form API. We should also take a look at Dojo=20
Toolkit.

BR,
Kaarle


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---